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

ui/views/focus/focus_manager.cc

 // Copyright (c) 2012 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 "ui/views/focus/focus_manager.h"
 
 #include <algorithm>
 #include <vector>
 
 #include "base/auto_reset.h"
@@ skipping 295 matching lines @@
       if (widget->widget_delegate()->ShouldAdvanceFocusToTopLevelWidget())
         widget = widget_;
       return GetNextFocusableView(NULL, widget, reverse, true);
     }
   }
   return NULL;
 }
 
 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
   // some listeners), then notify all listeners.
   focus_change_reason_ = reason;
   FOR_EACH_OBSERVER(FocusChangeListener, focus_change_listeners_,
                     OnWillChangeFocus(focused_view_, view));
 
   View* old_focused_view = focused_view_;
   focused_view_ = view;
@@ skipping 251 matching lines @@
   }
   if (key_code == ui::VKEY_RIGHT || key_code == ui::VKEY_DOWN) {
     AdvanceFocus(false);
     return true;
   }
 
   return false;
 }
 
 }  // namespace views