aura: Updates the text input client when native activation changes.

ui/views/focus/focus_manager.cc

Index: ui/views/focus/focus_manager.cc
diff --git a/ui/views/focus/focus_manager.cc b/ui/views/focus/focus_manager.cc
index b4bbd17cba9081be0fea01481b4bb9e41b0d2bdc..3a6bba730b544c482a522eaddb6a1b914a30db5d 100644
--- a/ui/views/focus/focus_manager.cc
+++ b/ui/views/focus/focus_manager.cc
@@ -313,8 +313,12 @@ View* FocusManager::GetNextFocusableView(View* original_starting_view,
 
 void FocusManager::SetFocusedViewWithReason(
     View* view, FocusChangeReason reason) {
-  if (focused_view_ == view)
+  if (focused_view_ == view) {
+    // In the case that the widget lost the focus and gained it back without
+    // changing the focused view, we have to make the text input client focused.

[msw, 2014/06/02 17:17:04]

When does the widget lose and regain focus without saving and restoring the
focused view? That seems like the root defect preventing the
[Blur|Focus]TextInputClient calls below to trigger as expected.

You said separately "Unlike direct call to {Focus,Blur}TextInputClient,
storing/restoring focused view does not always make call to
FocusTextInputClient." Is that truly what's happening (different from this
comment here), and if so why? That also seems like a more fundamental defect.

[Yuki, 2014/06/08 11:08:16]

Okay, I found the cause.  Here is the scenario.  Suppose you have two windows
and move the focus from one to the other one.

1. [activation change] NativeWidget's OnWindowActivated calls
RestoreFocusedView.  At this point, the focused view changes and the focused
text input client, too.
2. [focus change] FocusController resets the text input client first of all. 
After that, NativeWidget's OnWindowFocused calls RestoreFocusedView.  Since the
focused view doesn't change from the last time, we return at this line
immediately, and the focused text input client is left as null.

This is the scenario we're facing.

I think we cannot simply remove the call to RestoreFocusedView from
OnWindowActivated, and as I wrote before the order of activation/focus is wrong
at window creation time.

What do you think?  Can we go with this way or any better ideas?

[msw, 2014/06/10 04:05:08]

Hmm, maybe FocusController::SetFocusedWindow should not call
FocusTextInputClient(NULL) when a valid |window| is focused. Does removing that
call fix this defect without causing other issues?

[Yuki, 2014/06/10 05:59:00]

I understand that the reason why sky@ recommended to call
FocusTextInputClient(NULL) in FocusController is to guarantee that an invalid
(or already-died) text input client never gets focused.  From a point of view of
wm::FocusController, even when |window| is valid, it's not guaranteed that the
|window| sets the focus to the correct text input client.  Maybe it could be
forgotten.  That's the reason why sky@ highly recommended to call
FocusTextInputClient(NULL) here.

So, simply removing the call looks a bad idea to me.  It's |window|'s duty to
set the correct text input client focused, I think.

+    FocusTextInputClient(focused_view_);
     return;
+  }
 
   base::AutoReset<bool> auto_changing_focus(&is_changing_focus_, true);
   // Update the reason for the focus change (since this is checked by