linux: only create browser-side plugin container after plugin requests it

On Windows, windowed plugins are parented in a two-stage process: initially,
the plugin is parented to the render view, then later it's reparented to
a special per-plugin window.

On Linux, plugin embedding always needs a special per-plugin window before
it can be initialized.  So there's no way to do the two-stage initialization
process, and we only want to construct the browser-side plugin container for
windowed plugins after the plugin requests it.

Plumbing this through the WebPlugin interface will also allow us to side-route
this request for window creation out to the browser process in the
multi-process case.

BUG=15421
TEST=plugins still work in test_shell

Review URL: http://codereview.chromium.org/150034

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19560 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 6 deletions

diff --git a/webkit/glue/plugins/webplugin_delegate_impl_gtk.cc b/webkit/glue/plugins/webplugin_delegate_impl_gtk.cc
index c20fee0..9f9838b 100644
--- a/webkit/glue/plugins/webplugin_delegate_impl_gtk.cc
+++ b/webkit/glue/plugins/webplugin_delegate_impl_gtk.cc
@@ -263,12 +263,10 @@ bool WebPluginDelegateImpl::WindowedCreatePlugin() {
     return false;
   }
 
-  window_.window = reinterpret_cast<void*>(parent_);
-  // The remainder of the code expects windowed_handle_ to exist for
-  // windowed mode, despite not actually ever reaching through
-  // windowed_handle_.  It is still used as a token to represent "this
-  // plugin" in messages to the browser.
-  windowed_handle_ = parent_;
+  // Xembed plugins need a window created for them browser-side.
+  // Do that now.
+  windowed_handle_ = plugin_->CreatePluginContainer();
+  window_.window = reinterpret_cast<void*>(windowed_handle_);
 
   if (!window_.ws_info)
     window_.ws_info = new NPSetWindowCallbackStruct;