Redesigns the text input focus handling.

ui/views/widget/desktop_aura/desktop_native_widget_aura.cc

Index: ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
diff --git a/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc b/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
index 40b7225da9d3ceb2b8f97589e8a665170712d0d6..577cab1baf1e4130ecb1263b123fde02bb2b10e8 100644
--- a/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
+++ b/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
@@ -18,6 +18,7 @@
 #include "ui/aura/window_property.h"
 #include "ui/aura/window_tree_host.h"
 #include "ui/base/hit_test.h"
+#include "ui/base/ui_base_switches_util.h"
 #include "ui/compositor/layer.h"
 #include "ui/gfx/canvas.h"
 #include "ui/gfx/display.h"
@@ -38,8 +39,8 @@
 #include "ui/views/corewm/visibility_controller.h"
 #include "ui/views/corewm/window_modality_controller.h"
 #include "ui/views/drag_utils.h"
-#include "ui/views/ime/input_method.h"
 #include "ui/views/ime/input_method_bridge.h"
+#include "ui/views/ime/null_input_method.h"
 #include "ui/views/widget/desktop_aura/desktop_capture_client.h"
 #include "ui/views/widget/desktop_aura/desktop_cursor_loader_updater.h"
 #include "ui/views/widget/desktop_aura/desktop_dispatcher_client.h"
@@ -626,6 +627,9 @@ bool DesktopNativeWidgetAura::HasCapture() const {
 }
 
 InputMethod* DesktopNativeWidgetAura::CreateInputMethod() {
+  if (switches::IsNewTextInputFocusEnabled())
+    return new NullInputMethod();

[msw, 2014/03/11 00:58:50]

Is there an advantage to using NullInputMethod here, instead of NULL?

[Yuki, 2014/03/11 15:27:37]

NULL doesn't work.  Some of (not few) clients assume that GetInputMethod()
always returns non-NULL.

[msw, 2014/03/11 23:24:37]

Okay, then this is fine.

+
   ui::InputMethod* host = input_method_event_filter_->input_method();
   return new InputMethodBridge(this, host, false);
 }
@@ -635,6 +639,10 @@ internal::InputMethodDelegate*
   return this;
 }
 
+ui::InputMethod* DesktopNativeWidgetAura::GetHostInputMethod() {
+  return input_method_event_filter_->input_method();
+}
+
 void DesktopNativeWidgetAura::CenterWindow(const gfx::Size& size) {
   if (content_window_)
     desktop_window_tree_host_->CenterWindow(size);
@@ -1076,12 +1084,17 @@ void DesktopNativeWidgetAura::OnWindowFocused(aura::Window* gained_focus,
     desktop_window_tree_host_->OnNativeWidgetFocus();
     native_widget_delegate_->OnNativeFocus(lost_focus);
 
-    // If focus is moving from a descendant Window to |content_window_| then
-    // native activation hasn't changed. We still need to inform the InputMethod
-    // we've been focused though.
-    InputMethod* input_method = GetWidget()->GetInputMethod();
-    if (input_method)
-      input_method->OnFocus();
+    if (!switches::IsNewTextInputFocusEnabled()) {
+      // If focus is moving from a descendant Window to |content_window_| then
+      // native activation hasn't changed. We still need to inform the
+      // InputMethod we've been focused though.
+      InputMethod* input_method = GetWidget()->GetInputMethod();
+      if (input_method)
+        input_method->OnFocus();
+    }
+
+    views::FocusManager* focus_manager = GetWidget()->GetFocusManager();

[msw, 2014/03/11 00:58:50]

If the View focused before the Widget was deactivated was "stored" (blurred on
deactivate) and is going to be focused on Widget activation, has that already
happened? Or is the focused view going to be NULL here?

[Yuki, 2014/03/11 15:27:37]

OnWindowActivated() is called before OnWindowFocused(), and the stored view has
already been restored at this point.  Therefore
|focus_manager->GetFocusedView()| returns the focused view that we want.

[msw, 2014/03/11 23:24:37]

Great, thanks for checking. This may not actually be necessary if the
FocusManager is guaranteed to restore Focus to its last-focused View on
Activate, but I think having this explicit call is better than hoping the
implicit focus restoration does the same thing (at least for now). You might
want to add a comment here, explaining what this does, like "Ensure the focused
view's TextInputClient is used for text input."

[Yuki, 2014/03/12 09:13:15]

Done.

+    focus_manager->OnTextInputClientChanged(focus_manager->GetFocusedView());
   } else if (content_window_ == lost_focus) {

[msw, 2014/03/11 00:58:50]

Should we explicitly clear the TextInputClient in this case?

[Yuki, 2014/03/11 15:27:37]

I think we don't need to do so.

Losing the focus means that someone else is getting the focus right away.  So
the new focused window's view will soon set the focused TextInputClient.  So
there is no need to clear the TextInputClient explicitly here.

Actually there are 3 scenarios.
1. Another Chrome window gets the focus. => No problem as I wrote above. 
Another view gets the focus.
2. Another application gets the focus. => No problem because Chrome doesn't get
any input.
3. Chrome is terminating. => No problem because everything is soon gone.

We can clear the TextInputClient here, but I don't like to put such code outside
of FocusManager as much as possible.

[msw, 2014/03/11 23:24:37]

Hmm, I guess this should be okay; the focused View should be Blur()'ed on
deactivate anyway, and that'll do the same thing. I just have a slight
inclination to make this explicit like above, or make both implicit based on the
FocusManager doing a blur/focus on deactivate/active.

[Yuki, 2014/03/12 09:13:15]

This has been a tough question for me.  Now I've changed my mind and put calls
to {Focus,Blur}TextInputClient() here and above.

     desktop_window_tree_host_->OnNativeWidgetBlur();
     native_widget_delegate_->OnNativeBlur(