Issue metadata
Sign in to add a comment
|
Regression:Focus is lost after pressing tab key on cancel button for confirmation dialog box.
Reported by
vku...@etouch.net,
Feb 13 2017
|
||||||||||||||||||||
Issue descriptionChrome Version: 58.0.3011.0 (Official Build)Revision cc78776e3214ce8cd60288796a20baf7f98e7b52-refs/heads/master@{#449903} (64-bit) OS:Mac (10.12.1,10.11.6) What steps will reproduce the problem? (1)Launch chrome and click on avatar icon , sign in with valid credentials. (2)Click on undo button confirmation overlay and again sign in with different credentials (3)Press tab key and observe the focus. Actual: Focus is lost after pressing tab key on cancel button for Confirmation dialog box. Expected: Focus should traverse to radio button after pressing tab key on cancel button This is a regression issue broken in 'M57' and below is the manual regression range: Good Build: 57.0.2924.0 Bad Build: 57.0.2925.0 Note: Issue is not seen on Win & Linux OS.
,
Feb 13 2017
Note that this works fine on Linux and Windows, so it is probably something specific to macOS. It is unclear to me what piece of the UI takes the focus on macOS when user taps on tab.
,
Feb 14 2017
,
Feb 14 2017
,
Feb 14 2017
This issue is created as it looks like all the dialogs on Chrome macOS that use WebUI have this issue (see the bugs with title "Focus is lost ..."). From my initial debugging, it looks like Chrome on macOS moves the focus to the document.body. This is not observed on Windows and Linux (it looks like the behavior on Linux and Windows is the correct one). To get to this, I inspected the sign-in email confirmation dialog and logged the document.activeElement (in my case this was the body element). I have tried setting <body tabindex="-1"> to tell Chrome that body should not be focused, but it looks like Chrome macOS ignores this. I think the fix should be somewhere in Chrome macOS and not be specific to this dialog. Jayson: I am assigning this to you as I think Chrome have an different behaviour for focusing on macOS.
,
Feb 14 2017
ellyjones@ - can you take a look at this. Also, can you file a bug on the keyboard loop being backwards? The tabbing should go from radio button to Cancel to Continue. And finally, do you know where this dialog sits in the Harmonization process? Its raw Material Designiness (ripples, strange-looking gray focus style, shouty button titles) is very jarring.
,
Feb 15 2017
I think tapted@ knows more about WebUI than I do. This entire dialog is WebUI.
,
Feb 15 2017
I haven't done much WebUI. Triaging based on: > I have tried setting <body tabindex="-1"> to tell Chrome that body should not be focused, but it looks like Chrome macOS ignores this. (also this doesn't seem to be high priority, and doesn't seem like a regression, but someone from the sign-in team can probably fine-tune that)
,
Feb 20 2017
,
Feb 20 2017
Regarding on comment #5 https://html.spec.whatwg.org/multipage/interaction.html#dom-document-activeelement Document.activeElement would return <body> if nothing is focused on that document, and the document has <body> element. Setting "tabindex=-1" on body element doesn't turn off "focusability" of <body>, but to the contrary to it, it turns *on* focusability of <body>. The negative tabindex attribute causes Tab navigation not to stop on it, but the existence of tabindex makes the element focusable.
,
Feb 20 2017
How can I make the body element "unfocusable" on macOS?
,
Apr 18 2017
,
Apr 19 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by msrchandra@chromium.org
, Feb 13 2017Owner: msarda@chromium.org
Status: Assigned (was: Unconfirmed)