browser-plugin: Allow accepting drag-n-drop events.

content/browser/browser_plugin/browser_plugin_embedder.cc

Index: content/browser/browser_plugin/browser_plugin_embedder.cc
diff --git a/content/browser/browser_plugin/browser_plugin_embedder.cc b/content/browser/browser_plugin/browser_plugin_embedder.cc
index 091c00c90b0bb8c400514743bb4431de4d7e1599..3f001aee203f44361c98782ccae3a7e2e5e4086a 100644
--- a/content/browser/browser_plugin/browser_plugin_embedder.cc
+++ b/content/browser/browser_plugin/browser_plugin_embedder.cc
@@ -95,6 +95,7 @@ void BrowserPluginEmbedder::CreateGuest(RenderViewHost* render_view_host,
 
   guest = guest_web_contents->GetBrowserPluginGuest();
   guest->set_embedder_render_process_host(render_view_host->GetProcess());
+  guest->set_embedder_render_view_host(render_view_host);

[sadrul, 2012/10/09 23:09:42]

I believe this is safe because when a RenderViewHostImpl dies, it calls
delegate::RenderViewDeleted from its destructor, which is 
WebContentsImpl::RenderViewDeleted, which triggers
BrowserPluginEmbedder::DestroyGuests, which kills |guest|.

The same is the case for when the RenderViewHost receives a  RenderViewGone
message.

So from what I can see, at no point in |guest|s lifetime can there be a state
when the embedder RenderViewHost it points to is invalid.

[Fady Samuel, 2012/10/09 23:18:53]

Note: I was planning on deleting that line because it actually introduces a bug
with my postMessage patch where reload stops working because we end up
destroying all guests after we reload if a swapped out guest lives in the
embedder process destroys itself.

In a nutshell, this breaks reload. I'm going to retrace the stack for this
particular bug tomorrow and send you an email with more information because my
memory is a bit hazy on the details.

[sadrul, 2012/10/10 18:43:22]

You didn't mean this CL breaks reload, right? Because reloading the embedder or
the guest seems to work OK.

[Charlie Reis, 2012/10/10 19:04:32]

I don't see a big problem with telling the guest what the embedder's
RenderViewHost is, since any change to the embedder's RenderViewHost will
definitely get rid of its guests.

It is a bit odd to me that the BrowserPluginGuest doesn't know it's embedder,
though.  I guess that hasn't been needed, but that would let you find the
embedder's current RenderViewHost and RenderProcessHost without having to store
them separately.  Fady, is there a reason not to do that?

 
   RendererPreferences* guest_renderer_prefs =
       guest_web_contents->GetMutableRendererPrefs();
@@ -272,6 +273,17 @@ void BrowserPluginEmbedder::SetGuestVisibility(int instance_id,
     guest->SetVisibility(visible_, guest_visible);
 }
 
+void BrowserPluginEmbedder::DragStatusUpdate(
+    int instance_id,
+    WebKit::WebDragStatus drag_status,
+    const WebDropData& drop_data,
+    WebKit::WebDragOperationsMask drag_mask,
+    const gfx::Point& location) {
+  BrowserPluginGuest* guest = GetGuestByInstanceID(instance_id);
+  if (guest)
+    guest->DragStatusUpdate(drag_status, drop_data, drag_mask, location);
+}
+
 void BrowserPluginEmbedder::Go(int instance_id, int relative_index) {
   BrowserPluginGuest* guest = GetGuestByInstanceID(instance_id);
   if (guest)