[reland] Browser Side Text Input State Tracking for OOPIF (Aura Only)

content/browser/web_contents/web_contents_impl.cc

Index: content/browser/web_contents/web_contents_impl.cc
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index 56738c74d37f7ba1c7cd4b8560fbbc86c3c13173..7124b200ca716c72feb98ae1eab793b1cc56cb89 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -65,6 +65,7 @@
 #include "content/browser/renderer_host/render_widget_host_impl.h"
 #include "content/browser/renderer_host/render_widget_host_input_event_router.h"
 #include "content/browser/renderer_host/render_widget_host_view_base.h"
+#include "content/browser/renderer_host/text_input_manager.h"
 #include "content/browser/screen_orientation/screen_orientation_dispatcher_host_impl.h"
 #include "content/browser/site_instance_impl.h"
 #include "content/browser/wake_lock/wake_lock_service_context.h"
@@ -2364,6 +2365,25 @@ void WebContentsImpl::SendScreenRects() {
     browser_plugin_embedder_->DidSendScreenRects();
 }
 
+TextInputManager* WebContentsImpl::GetTextInputManager() {
+  if (GetOuterWebContents()) {
+    if (text_input_manager_) {
+      // Since the outer WebContents exists, we should destroy
+      // |text_input_manager_| which will in turn notify all the
+      // RenderWidgetHostViews.
+      // TODO(ekaramad): Is this the right way to for IME handoff?

[kenrb, 2016/05/12 16:16:37]

I have concerns about this, there were problems with the similar pattern for
accessing RenderWidgetHostInputEventRouter. If there is a RenderWidgetHostView
registered on the inner WebContents, how does it re-register with the outer
WebContents? This gets especially hard to reason about in the case of
RenderWidgetHostViewGuest which proxies calls to a platform RenderWidgetHostView
that it owns. At the very least you should ensure your changes are tested with
WebView in both OOPIF and non-OOPIF modes.

[EhsanK, 2016/05/13 16:00:56]

Indeed, the case with <webview> is very tricky. As for this patch,
non-OOPIF-<webview> is not affected as I am keeping the old TextInputState
mechanism for RenderWidgetHostViewGuest. RWHVGuest normally reports its
TextInputState to embedder (outer) tab-RWHV. So, from a tab-RWHV's perspective,
the TextInputState has come from its own RenderWidget. This is racy but has been
like this for a while now (crbug.com/546645).
For OOPIF-<webview> this will not work as is. I am intending to fix that after
landing this and IME for OOPIF. The solution I had in mind was to make all RWHV
observer TextInputManager's destruction. This way, when attaching, all RWHV in
inner WebContents will lose their reference to TextInputManager and then try to
reinitialize and end up getting the one from outer WebContents. The complication
is that we have to restore the current state after attachment. Although this
only happens if there has been a TextInputState before attaching to start with.
All in all, I think we should look at <webview> after this.

+      // (crbug.com/609846).
+      text_input_manager_.reset(nullptr);
+    }
+    return GetOuterWebContents()->GetTextInputManager();
+  }
+
+  if (!text_input_manager_)
+    text_input_manager_.reset(new TextInputManager());
+
+  return text_input_manager_.get();
+}
+
 BrowserAccessibilityManager*
     WebContentsImpl::GetRootBrowserAccessibilityManager() {
   RenderFrameHostImpl* rfh = GetMainFrame();