Reproduced twice on kevin M60-9592.8.0/60.0.3112.10

antrim@, are you the right owner for this one?

Any updates? M60 goes stable in 3 weeks.

Antrim/rkc, any update on this issue? 

This might be the same as  issue 713459  (also reported by me). No progress on that one either, though.

Colin, could you sync with Jacob on  issue 713459  and investigate this?

I can repo and I'm investigating this.

This issue is no long a problem as we've enabled password typing when the field is not focused ( issue 695558 ). We still need to figure out why the focus was lost in the first place.

Thanks, and yes, this still needs to be fixed. I suspect that many users won't try typing their password if the user pod is unfocused.

I can repo  issue 713459 , and for this one, I do observe that the focus is sometimes lost when there's a popup notification, but here do you mean the focus is lost while typing password without any obvious reason? That's very bad but I never encountered with that yet. Can you provide with more specific repo steps? Thanks!

I don't know that I've seen this recently.  I still frequently see the password field initially start out unfocused (both at the login and lock screens).

I could believe that there's a race where the focus gets stolen early on, possibly before the user has started typing and possibly after they've started. Does that seem plausible?

It is plausible. There are two 'unfocused' states: 1) The password field is still seen, but the cursor is not there, or 2) The password field is invisible. I've seen 1) at login screen (very rarely though) but never see 2). 2) is much more serious so please give an update when it's seen. Thanks.

Thanks, I'll pay attention the next time I see it. I believe I've only seen 1, though -- the password field is visible but unfocused, as if I'd clicked somewhere else on the screen.

Removing RBS based latest comments, we can still evaluate a merge to M60 once solution identified and low risks

jdufault@, can you take a look at this one? This existed before the UI revamp but seemed to surface very often recently.

Here are logs generated with https://chromium-review.googlesource.com/c/590171/ patched in. In both cases, I tapped the power button to force the display off and lock, and then tapped it again 1-2 seconds later to force it back on. In focused.txt, the password field was focused and I unlocked the screen. In unfocused.txt (the next attempt), I didn't do anything else after seeing that the password field was unfocused.

"!! WebUILoginView::RequestFocus" was logged in both cases, but only the focused case had this:

[1129:1129:0727/145017.904383:ERROR:CONSOLE(9556)] "!!!! detectFocus document.activeElement=[object HTMLInputElement]", source: chrome://oobe/lock.js (9556)
[1129:1129:0727/145017.905521:ERROR:CONSOLE(9564)] "Error
    at detectFocus (chrome://oobe/lock.js:9564:19)
    at HTMLDivElement.focusInput (chrome://oobe/lock.js:5692:22)
    at HTMLDivElement.reset (chrome://oobe/lock.js:5786:16)
    at HTMLDivElement.f (chrome://oobe/lock.js:8772:22)", source: chrome://oobe/lock.js (9564)

Deleted: focused.txt 5.6 KB

focused.txt 5.6 KB View Download

Deleted: unfocused.txt 4.0 KB

unfocused.txt 4.0 KB View Download

https://chromium-review.googlesource.com/c/590171/

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

commit ef5c4de93592d5b4dc47000143a9e2e2ad151d52
Author: Jacob Dufault <jdufault@google.com>
Date: Fri Jul 28 22:56:33 2017

cros: Ensure password view has focus when showing lock screen.

Bug:  725622 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Iaf48cb74746a466f5856edc953972e9362b19ebc
Reviewed-on: https://chromium-review.googlesource.com/590171
Commit-Queue: Jacob Dufault <jdufault@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490531}
[modify] https://crrev.com/ef5c4de93592d5b4dc47000143a9e2e2ad151d52/ui/login/account_picker/md_user_pod_row.js

Your change meets the bar and is auto-approved for M61. Please go ahead and merge the CL to branch 3163 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit f776da3003746c680ecfe1a3eb7eba4b321ae1e4
Author: Jacob Dufault <jdufault@google.com>
Date: Thu Aug 03 20:16:51 2017

cros: Ensure password view has focus when showing lock screen.

TBR=jdufault@google.com

(cherry picked from commit ef5c4de93592d5b4dc47000143a9e2e2ad151d52)

Bug:  725622 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Iaf48cb74746a466f5856edc953972e9362b19ebc
Reviewed-on: https://chromium-review.googlesource.com/590171
Commit-Queue: Jacob Dufault <jdufault@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#490531}
Reviewed-on: https://chromium-review.googlesource.com/601123
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#285}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/f776da3003746c680ecfe1a3eb7eba4b321ae1e4/ui/login/account_picker/md_user_pod_row.js

The issue is fixed in 62.0.3174.0 but reappears in 62.0.3176.0. I'm doing a bisect.

The focus is always missing when it's connected to Ethernet. Under wifi the focus may appear at the beginning, but if you connect a cable and right at the moment it's connected, the focus is lost. Doesn't look like coincidence.

https://chromium-review.googlesource.com/c/591628 is the commit.

That change only changes the trybot configuration, it shouldn't have any effect in behavior.

Eric mentioned today that he saw the field lose the focus today after he started typing his password on a recent-ish build (as opposed to starting out unfocused).

Adding Steven for ideas about the network angle.

Re#25, the change doesn't seem to be related indeed, but if you revert to the one commit previous to yours (#491455), the issue disappears immediately, which is strange. Can you give it a try?

It's conceivable that updating the network icon is stealing focus? There have been changes to that code related to Tether, but it seems unlikely that the changes would affect focus.

I just saw this again:

Google Chrome	61.0.3163.38 (Official Build) dev (64-bit)
Platform	9765.21.0 (Official Build) dev-channel ...

I was trying to sign into a second account. I got two characters into the password field before it lost focus.

I've also seen this happen on one of the builds over the last few days.

Yea, I've also noticed it when deploying a build recently.

Strangely the HTML webpage thinks the password field is focused.

+avallee

Considering how late this is in the cycle, upping the priority.
Jacob, let me know if there is any way I can help with this. If this is a blink issue, we should contact the relevant owners ASAP.

I'm doing a bisect now.

Bisect has revealed https://chromium-review.googlesource.com/c/chromium/src/+/591628 as the bad CL.

This is the same bad commit found in #24 via a separate bisect. This is extremely reproducable.

    # Bad commit - notice that the password field loses focus after 1-2 seconds.
    $ git checkout a3fd83c8e17555d176368f36a7108ed3c2365691
    $ ninja -C out/Release -j1000 chrome ;and ./out/Release/chrome --user-data-dir=/tmp/foobar2 --login-manager
    
    # Good commit - password field maintains focus.
    $ git checkout a3fd83c8e17555d176368f36a7108ed3c2365691^
    $ ninja -C out/Release -j1000 chrome ;and ./out/Release/chrome --user-data-dir=/tmp/foobar2 --login-manager
 

Reducing to P1, if this is caused by my change above it is not enabled on beta or stable channels.

 Issue 757514  has been merged into this issue.

So, I've looked at the bug, and it happens because of a change of behavior. Before, we didn't use to allow the <webview>'s to steal focus from the embedder process, but after my change this is possible (which is the same behavior as iframes). Given that <webview> didn't use to allow this, I'll put up a CL to revert to the old behavior.

That said, there's one more interesting bit I discovered while investigating. At the CrOS login screen, we create a hidden <webview> that navigates to 'accounts.google.com'. Is there a reason for having a hidden <webview> that loads another page while the user sees the login screen?

The hidden <webview> is an optimization so that when user clicks on "Add Person" we can show the preloaded Gaia. Otherwise, user would wait for a few seconds for it to load (https negotiation is kind of slow).

Implemented in early days in https://codereview.chromium.org/8372093.

I guess this is the new version of old  issue 206723 ...

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

commit abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Tue Aug 29 19:37:57 2017

Prevent an inner WebContents from stealing focus from an outer WebContents.

An inner WebContents will only allow itself to be focused in two cases:
  - When the outer WebContents has focus and advances focus to the inner
  WebContents.
  - When an outer WebContents has focus and focus the inner WebContents
  through window.focus() API.

Bug:  725622 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: If8ef4ed3386eadc2bb22c3afa7701d627c13eb39
Reviewed-on: https://chromium-review.googlesource.com/636624
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498203}
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/browser/frame_host/render_frame_host_delegate.h
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/browser/frame_host/render_frame_proxy_host.cc
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/public/test/browser_test_utils.cc
[modify] https://crrev.com/abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c/content/public/test/browser_test_utils.h

Requesting merge to M61.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M61.

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

commit a42ac877f530f9565f59e7041984b365ebb2b9ad
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Wed Aug 30 20:09:38 2017

Prevent an inner WebContents from stealing focus from an outer WebContents.

An inner WebContents will only allow itself to be focused in two cases:
  - When the outer WebContents has focus and advances focus to the inner
  WebContents.
  - When an outer WebContents has focus and focus the inner WebContents
  through window.focus() API.

Bug:  725622 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: If8ef4ed3386eadc2bb22c3afa7701d627c13eb39
Reviewed-on: https://chromium-review.googlesource.com/636624
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498203}
(cherry picked from commit abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c)

TBR=alexmos@chromium.org,wjmaclean@chromium.org

Change-Id: If8ef4ed3386eadc2bb22c3afa7701d627c13eb39
Reviewed-on: https://chromium-review.googlesource.com/644226
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#1003}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/browser/frame_host/render_frame_host_delegate.h
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/browser/frame_host/render_frame_proxy_host.cc
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/public/test/browser_test_utils.cc
[modify] https://crrev.com/a42ac877f530f9565f59e7041984b365ebb2b9ad/content/public/test/browser_test_utils.h