Inconsistent focus move after executing toolbar commands by keyboard |
|||||||
Issue descriptionChrome Version: 63.0.3231.0 (1) Choose "switch to thumbnail view" toolbar button by [tab] key and trigger it by [enter]. (2) Also do the same for [sort options]-[Date modified] menu item. Some buttons moves focus to the file list view but others don't. This will result in inconsistent response to user's operations. - View mode button moves the focus to the file list. - Focus stays on the button after choosing: - any sort key in the sort menu button - [show hidden files] in [More...] menu button - Focus moves to an invisible element when: - any ancestor directory name button in the breadcrumb - delete button This affects the keyboard operation directly, but also affects in case of mouse/touchscreen like Issue 748489 . We handle the view mode button as a special case in response to Issue 493039 . If we expect [ctrl]+[A] should choose the all files in the list after a ceratin operation, we should move the focus back to the file list after it.
,
Oct 5 2017
+weifangsun@ FYI This is super interesting, thanks for investigating this. There is one more case when focus moves to an invisible element, if no file was in focus (single-select) when the operation was performed (like list/thumbnail view toggle). My intuition is to reset focus to an invisible element as a default with a few exceptions: - Deleting a file with the delete button should move focus to the next file in the list. - If a file is in focus when the user tabs up to the toolbar focus should return to that file. Adding Laura too to see if this makes sense from an accessibility standpoint.
,
Oct 10 2017
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3104225e0398bcf5655ce9ff909c8da4db2f68e7 commit 3104225e0398bcf5655ce9ff909c8da4db2f68e7 Author: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Date: Tue Dec 12 04:17:58 2017 Keep focus on the original place when closing menu by mouse or touchscreen. This will also affect other UI elements derived from cr.ui.MenuButton like: - Combo Button - Context Menu Button The UI elements are also referred in other places than the Files app. - "Apps" menu in login screen - media control UI in the video player - Bookmark Manager The button is made not to steal the focus when clicking it to open menu, https://cs.chromium.org/chromium/src/ui/webui/resources/js/cr/ui/menu_button.js?q=file:menu_button.js+stealing+focus&sq=package:chromium&dr&l=139 however, it had taken focus when the menu item is activated by a click. It made the focus left on the button after finishing operation on a button using either mouse or touchscreen, requiring MenuButton class to hide that focus highlight by attaching "using-mouse" class attribute. Test: browser_tests --gtest_filter=WebUIResourceBrowserTest.MenuButtonTest* Bug: 771024 , 769593 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I23fb1b0ce907a21407ffca514032bfdc083e36de Reviewed-on: https://chromium-review.googlesource.com/816376 Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Cr-Commit-Position: refs/heads/master@{#523331} [modify] https://crrev.com/3104225e0398bcf5655ce9ff909c8da4db2f68e7/chrome/test/data/webui/menu_button_test.html [modify] https://crrev.com/3104225e0398bcf5655ce9ff909c8da4db2f68e7/chrome/test/data/webui/webui_resource_browsertest.cc [modify] https://crrev.com/3104225e0398bcf5655ce9ff909c8da4db2f68e7/ui/webui/resources/js/cr/ui/menu_button.js
,
Feb 23 2018
Is this fixed? :)
,
Feb 28 2018
,
Feb 28 2018
,
Mar 1 2018
I think the current state is ok for users. Closing out for now. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by fukino@chromium.org
, Oct 3 2017