Regression:Focus issue is seen for languages in chrome://md-settings
Reported by
adha...@etouch.net,
Oct 26 2016
|
|||||||||||
Issue descriptionVersion: 56.0.2900.0 (Official Build) canary 1e4fbec3b5701d9f605e88f14dafa442be98b648-refs/heads/master@{#427219} (32/64-bit) OS: Windows (7,8,10), Mac(10.10.5, 10.11.4), Linux (14.04 LTS) What steps will reproduce the problem? (1)Launch Chrome and navigate to chrome://md-settings/languages. (2)Click on the drop down arrow of the Language section. (3)Click on the iron icon of the first language.i.e English (4)Now press 'Tab' key from keyboard and observe the focus.(Kindly refer the video) Actual:Focus shifts directly to "CHANGE" button. Expected:Focus should traverse properly through all options. This is a Regression issue broken in M-56,will soon update other info. Good build:56.0.2891.0 Bad build:56.0.2894.0
,
Oct 26 2016
,
Oct 26 2016
Weird, I haven't seen this before.
,
Oct 27 2016
Performed bisect for this issue and got the below CL. Bisect Information: ------------------------ You are probably looking for a change made after 422037 (known good), but no later than 422038 (first known bad). CHANGELOG URL: ---------------- https://chromium.googlesource.com/chromium/src/+log/932d7f1488771d98c3519ffca0ca84deca523d05..93a39a3cfff736b8e10f65e9d7bf2612186a26c8
,
Oct 28 2016
This looks like it might be related to the dialog change for the overflow menu
,
Oct 28 2016
A decision was made to close the action menu on "tab". User can use up/down arrows to navigate through the options. This matches what cr-shared-menu was doing already (although it was only used in a few places, and languages was not one of them). @dbeam: Please re-open if you think that closing the action menu on "tab" is not a good experience.
,
Oct 31 2016
dpapad: can you clarify whether "tab" should, after closing the action menu, move to the next list item's 3-dot menu button? Because the other issue here is that pressing Tab actually jumps the focus *to the next section*, bypassing all the 3-dot menu buttons for the remaining rows in the list.
,
Oct 31 2016
@michaelpg: You are right that current behavior (bypassing the entire list and going to next section) is fairly odd. It seems to me that the least surprising behavior is to return focus to the "anchor" element that was used to position the action menu, which is the 3-dot menu button of current item (not next one). This seems also easier to implement (see https://codereview.chromium.org/2464873003 and attached screencast).
,
Oct 31 2016
,
Nov 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/140f168199593fafe11b6a568cdfa99b4d1c9bda commit 140f168199593fafe11b6a568cdfa99b4d1c9bda Author: dpapad <dpapad@chromium.org> Date: Thu Nov 03 00:13:00 2016 WebUI: Return focus to anchor element when cr-action-menu is closed. The default <dialog> restore focus behavior is not very intuitive (or clear) and certainly does not match the user's expectation when an action menu is closed. Action menu should define its own behavior that matches user's focus expectations, instead of just relying on <dialog>'s behavior. BUG= 659567 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2464873003 Cr-Commit-Position: refs/heads/master@{#429468} [modify] https://crrev.com/140f168199593fafe11b6a568cdfa99b4d1c9bda/chrome/test/data/webui/cr_elements/cr_action_menu_test.js [modify] https://crrev.com/140f168199593fafe11b6a568cdfa99b4d1c9bda/ui/webui/resources/cr_elements/cr_action_menu/cr_action_menu.js
,
Nov 3 2016
,
Nov 23 2016
Verified on ChromeOS 9011.0.0, 57.0.2926.0 |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by tkonch...@chromium.org
, Oct 26 2016Status: Untriaged (was: Unconfirmed)