I couldn't reproduce this on 49.0.2623.81. After waking the laptop up, I was able to type in the password to log in, and once logged in the httpauth was on the screen.

However, I can reproduce this 52.0.2743.32. The same steps resulted in the httpauth having focus.

+oshima: This isn't a security issue (removing security restrictions), but it is a regression bug. Can you help triage / find an owner for this?

this may be related to  crbug.com/620406  that I noticed recently. Let me look into this first.

Actually, this is different from  crbug.com/620406 .

Here is what's happening

1) view's FocusManager sets the Focus to the view and calls OnFocus, even though its window does not have a focus
2) chromeos (ash) correctly rejects activating and focusing the window behind lock screen.
3) chromeos (ash) correctly select the lock window as a target for key events
4) InputMethodChromeOS receives this event, but send it to the wrong client set in 1), even though the target is different.

warx@, can you work on fixing 1) I'll explain how.

4) is also needs to be fixed because calling just SetFocusedTextInputClient will lead to the similar problem.

shuchen@, I think it needs to reject the event if it's sent to the different target. Can you or someone in your team work on 4)? I think it just need to get native window from client and make sure it can receive events.

From #1, it looks like this bug is a regression? Would a bisect help here?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c16e0e849526c1c627e08a05351ab38a9cfbcf1

commit 5c16e0e849526c1c627e08a05351ab38a9cfbcf1
Author: warx <warx@chromium.org>
Date: Fri Oct 21 21:55:46 2016

Do not give instant focus if a view's toplevelwidget is not active

If the top level widget isn't active during setting focus view, we store the focused view and then attempt to activate the widget. If activation succeeds view will be focused. If activation fails |view| will be focused the next time the widget is made active.

Based on this rule, a set of unittests related are modified.

This is a following up CL for 2113163002 as there are already too many patches there.

BUG= 621791 
BUG= 650776 
BUG= 152938 
TEST=add an interactive_ui_test, NativeWidgetAuraTest.NonActiveWindowRequestImeFocus

Review-Url: https://chromiumcodereview.appspot.com/2371113003
Cr-Commit-Position: refs/heads/master@{#426905}

[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ash/common/system/tray/tray_details_view_unittest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/chrome/browser/ui/ash/accessibility/ax_tree_source_aura_unittest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/chrome/browser/ui/views/apps/app_info_dialog/app_info_dialog_ash_unittest.cc
[delete] https://crrev.com/b07f20559996aa8154a3a67e742676a9799e37c4/chrome/browser/ui/views/toolbar/toolbar_view_browsertest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/chrome/browser/ui/views/toolbar/toolbar_view_interactive_uitest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/chrome/test/BUILD.gn
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/controls/combobox/combobox_unittest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/focus/focus_manager.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/mus/native_widget_mus.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/view_targeter_unittest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
[add] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/widget/native_widget_aura_interactive_uitest.cc
[modify] https://crrev.com/5c16e0e849526c1c627e08a05351ab38a9cfbcf1/ui/views/widget/root_view_unittest.cc

pass the issue to shuchen@ for comment 3(4)

Re #3, oshima@, can you please point out the code points where FocusManager calls view's OnFocus?

I don't think it is a good idea to make implementations (e.g. InputMethodChromeOS) directly depend on aura/views.
I would recommend to let FocusManager avoid calling SetFocusedTextInputClient() when the window is not activated (at front).

oshima@, can you please address #10? Thanks.

<triage> Cannot reproduce on 72.0.3593.0, please reopen if seen again. </triage>