[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 3362cc1b63417be749ef6832eabd73c03b175083..98262726a59ea4dded72748272fdb0066f228256 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"
@@ -1414,6 +1415,13 @@ void WebContentsImpl::AttachToOuterWebContentsFrame(
   static_cast<RenderWidgetHostViewChildFrame*>(
       render_manager->GetRenderWidgetHostView())
       ->RegisterSurfaceNamespaceId();
+
+  // At this point, we should destroy the TextInputManager which will notify all
+  // the RWHV in this WebContents.

[Charlie Reis, 2016/05/18 20:46:05]

What is this accomplishing for the inner WebContents?  I'm not sure I follow
this.

[EhsanK, 2016/05/24 20:42:46]

On line 2376, we return the outer WebContents TextInputManager. If a WebContents
is attached to outer WebContents, its own TextInputManager should be destroyed.

+  // TODO(ekaramad): Is this the right way to for IME handoff? Is it possible to

[Charlie Reis, 2016/05/18 20:46:05]

Not sure I understand this TODO.  (Right way to what?)

[EhsanK, 2016/05/24 20:42:46]

Me neither yet. This only affects OOPIF-<webview> and should be dealt with soon
after OOPIF IME. Traditionally, in BrowserPluginGuest-based <webview>, we call
TextInputStateChanged() on RWHVGuest in some specific occasions. For example,
here when <webview> is focused:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/br...

I am not yet quite certain if the same logic is necessary for OOPIF <webview>.
Two simple scenarios I can think of (not confirm either):
1- We will never have meaningful TextInputState inside inner WebContents before
it is attached. In that case, destroying the TextInputManager is enough.

2- We might have meaningful state, OR, we need to update the state when
<webview> gets focused. I don't know the answer to this yet. 

This should be resolved later (soon after OOPIF) when dealing with
<webview>-IME. Also to clarify, this does not affect non-OOPIF <webview> so
current <webview> IME should be fine as long as OOPIF IME is fine.

+  // have TextInputState (not none) before attaching? If so, we need to restore
+  // it (crbug.com/609846).
+  text_input_manager_.reset(nullptr);
 }
 
 void WebContentsImpl::Stop() {
@@ -2364,6 +2372,16 @@ void WebContentsImpl::SendScreenRects() {
     browser_plugin_embedder_->DidSendScreenRects();
 }
 
+TextInputManager* WebContentsImpl::GetTextInputManager() {
+  if (GetOuterWebContents())
+    return GetOuterWebContents()->GetTextInputManager();
+
+  if (!text_input_manager_)
+    text_input_manager_.reset(new TextInputManager());
+
+  return text_input_manager_.get();
+}
+
 BrowserAccessibilityManager*
     WebContentsImpl::GetRootBrowserAccessibilityManager() {
   RenderFrameHostImpl* rfh = GetMainFrame();