Fix issue that IME can't be enabled when set Plugin mode to "Click to play".

components/plugins/renderer/plugin_placeholder.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "components/plugins/renderer/plugin_placeholder.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/json/string_escape.h"
 #include "base/strings/string_piece.h"
@@ skipping 194 matching lines @@
     NOTREACHED();
     return;
   }
 
   // TODO(mmenke):  In the case of prerendering, feed into
   //                ChromeContentRendererClient::CreatePlugin instead, to
   //                reduce the chance of future regressions.
   WebPlugin* plugin =
       render_frame()->CreatePlugin(frame_, plugin_info_, plugin_params_);
   ReplacePlugin(plugin);
+  plugin->updateFocus(true);

[Bernhard Bauer, 2014/01/22 10:15:09]

Hmm... I'm somewhat worried that this will unconditionally set the focus on the
plugin. Could we keep a |focused_| flag in WebViewPlugin instead, then transfer
that flag to the new plugin when we load it?

[Ruiyi Luo, 2014/01/24 13:18:22]

Hello Bernhard, 

Thanks. I will do more debug here. 

1. At "Click to play" mode, the first time when we click the Plugin container(No
plugin loaded), it will set everything as the plugin has been loaded, except the
WebPluginContainerImpl::setFocus(true), where no plugin instance, and no
inherited function is available, thus noting was set there. If this loadPlugin()
will not only called only by situation "Click to play", I think this solution is
acceptable, at least, we put focus into the plugin container. And we know, for
"Run automatically", the plugin will be created elsewhere when the page is
created. 

2.  After the plugin is loaded, however, every time we clicked, the focused
element and the oldFocusedElement will be the same. 
FocusController.cpp line:626. Or else, we could reset the focused element in the
document to NULL after the plugin is loaded.
 
3. WebViewPlugin seems not involved here. 

Any more suggestion?

[Bernhard Bauer, 2014/01/24 13:37:53]

Well, WebPluginContainerImpl will call WebPlugin::updateFocus(). While we are
showing a placeholder, the plugin will be a WebViewPlugin, where updateFocus()
is implemented with an empty body.

What I'm suggesting is that we implement WebViewPlugin::updateFocus() to store
the focused flag, and then transfer that flag to the real plugin when we load
it. If the WebViewPlugin gets focus, this should have the exact same effect as
the current patch.
I'm not exactly sure I understand what you are saying here, but there are other
ways that blocked plugins can be run: via the context menu, and via the blocked
plugin icon in the omnibox. I don't think the context menu would give focus to
the plugin (only a left click does), and the blocked icon bubble is outside of
the content area anyway.
Right, this is correct, because from the point of view of the web page, nothing
should change if we load the real plugin. 
WebViewPlugin is the implementation of WebPlugin that we use initially to draw
the placeholder.

 }
 
 void PluginPlaceholder::LoadCallback() {
   RenderThread::Get()->RecordAction(UserMetricsAction("Plugin_Load_Click"));
   LoadPlugin();
 }
 
 void PluginPlaceholder::HideCallback() {
   RenderThread::Get()->RecordAction(UserMetricsAction("Plugin_Hide_Click"));
   HidePlugin();
@@ skipping 18 matching lines @@
   identifier_ = identifier;
 }
 
 blink::WebFrame* PluginPlaceholder::GetFrame() { return frame_; }
 
 const blink::WebPluginParams& PluginPlaceholder::GetPluginParams() const {
   return plugin_params_;
 }
 
 }  // namespace plugins