New issue
Advanced search Search tips

Issue 840181 link

Starred by 3 users
Status: Available
Owner:
kenrb@chromium.org
Cc:
alex...@chromium.org
wfh@chromium.org
creis@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

focus loss

Project Member Reported by rjkroege@chromium.org, May 6 2018 
Chrome Version: 68.0.3418.2 (Official Build) dev (64-bit)
Revision	21ed427687d402ad4eb216ae47655d044bce655a-refs/branch-heads/3418@{#4}
OS: MacOS

What steps will reproduce the problem?
(1) make a window A
(2) make a window B in a different profile. (That it's a different profile may not be relevant)
(3) attempt to sign into a google profile in window B. start typing in text field
(4) switch with keyboard shortcut to window A to look something up (in this case, the email address to use when signing in)
(5) switch back via keyboard shortcut to B


What is the expected result?

I'd expect the text field in B (the google account dialog, almost certainly an OOPIF) to have focus.

What happens instead?

Focus must be put back on the email field by clicking in it.

I claim that this is probably a bug in how focus is managed with OOPIFs. kenrb@ can you direct appropriately?

Comment 1 by lukasza@chromium.org, May 7 2018 

FWIW, I can't repro with the following repro steps on Chrome Mac 68.0.3423.0:

1. Open Chrome Canary
2. Open an incognito window
3. Navigate the incognito window to http://anforowicz.github.io/undo-test/index.html
4. Optional: verify in Chrome Task Manager that a separate subframe process exists for "Incognito Subframe: https://anforowicz.github.io" (i.e. that Site Isolation is turned on)
5. Use Macbook's touch pad to focus the Input1 field in the second (https) subframe.
6. Type some gibberish into the text field
7. Press ⌘-tilde to switch to the other Chrome window
8. Press ⌘-tilde again to switch back to the incognito window
9. Resume typing with no focus issues

I also did not repro when in step3 I navigated the incognito window to https://mail.google.com (which triggered an OAuth flow going through https://accounts.google.com although I note that this was a top-level frame rather than an OOPIF).

Comment 2 by kenrb@chromium.org, May 7 2018

Cc: alex...@chromium.org
Adding Alex.

Comment 3 by alex...@chromium.org, May 7 2018 

I think we'll need more details here.  I also couldn't repro locally on Mac canary - I tried something similar to Lukasz's steps with an incognito profile, and also on chrome://chrome-signin.  rjkroege@: can you please be more precise about how you arrive at the sign-in page, which shortcuts you're using, whether the lookup steps in window A matter for this, etc.? 

While accounts.google.com indeed requires a dedicated process, and hidden accounts.google.com iframes on other pages do go into OOPIFs, AFAIK the flow to enter credentials always take place in a main frame, so actual username/password entry wouldn't happen in an OOPIF.  There might be some OOPIFs on accounts.google.com itself, but those are hidden iframes to handle auth for youtube.com, etc., and shouldn't be used when entering credentials.  Of course, it's still possible that they affect focus somehow, so we should try to narrow down repro steps.

Comment 4 by erikc...@chromium.org, May 16 2018

Status: ss (was: Untriaged)

Comment 5 by erikc...@chromium.org, May 16 2018

Status: Assigned (was: Ss)

Comment 6 by rjkroege@chromium.org, May 16 2018 

I'll get around to trying to craft a more robust repro.
Project Member

Comment 7 by sheriffbot@chromium.org, Jun 18 2018

Status: Available (was: Assigned)
--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

Comment 8 by benhenry@chromium.org, Aug 2

Status: Assigned (was: Available)
Project Member

Comment 9 by sheriffbot@chromium.org, Sep 3

Status: Available (was: Assigned)
--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

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

Sign in to add a comment