Chrome combo boxes treat keyboard input differently than native Windows ones
Reported by
mr.ber...@gmail.com,
Jun 16 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 Steps to reproduce the problem: For example, follow the steps in Issue 585122 . Other places where this is happening: 1. chrome://settings/syncSetup (focus the top combo box, select "sync everything", type cs fast - it will not go to back "sync everything" and be stuck at "choose what to sync". 2. chrome://settings/, "Set which search engine is used when searching from the omnibox.": Focus combo box, type (e.g.) the letter "e" for "ebay", then quickly "e" again for "extra" (or whatever else you have with "e"). Selection will be stuck at "ebay". 3. I don't know where else combo boxes are used. What is the expected behavior? I expect to be able to cycle between elements of the combo box quickly. In particular, holding "B" pressed in the "add bookmarks" dialog should cycle between all folders beginning with "B" (except when there's one called "BBBBB", maybe). What went wrong? For some reason, non-matching incremental input is eaten up. Instead of cycling between all "B"s, the selection is stuck with the first one and never comes back from there if you hold B (or keep pressing it faster than some thresholds - feels like every 2 seconds). Windows combo boxed behave differently in that case, and I prefer a common behavior across all combo boxes in my OS. Compare what Word 2016 does. Type text, highlight it, press Ctrl-D, Advanced, "Stylistic sets". It has a dropdown featuring entries "Default" and numbers from "1" to "20". This is an ideal test case, since it has an "11", but no "22". In particular, pressing and holding "2" will quickly cycle between "2" and "20". (Pressing and holding "1" will not due to the existence of "11", which I don't like, but I acknowledge that's a difficult edge case.) Another way to try this is to compare what Chrome does with this website: <html><body><select> <option>ebay1</option> <option>ebay2</option> </select></body></html> Holding e pressed cycles through all the elements. Clearly, one would expect all combo boxes in Chrome to behave the same, regardless of whether it's UI or web content natively rendered by Chrome. Did this work before? N/A Chrome version: 51.0.2704.84 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 This is a generalization of Issue 585122 , which has a wider impact than I originally noticed.
,
Jun 16 2016
[msw]: Looks like your CL changed this.
,
Jun 16 2016
The Views (browser UI) comboboxes (like the Bookmark Bubble's "Folder") have a different implementation than any comboboxes in web content (like those in chrome://settings or any website). Changing Views combobox timing is easy, but it'd effect tree views (Edit Bookmark dialog, etc.) and menus (see PrefixDelegate users). https://cs.chromium.org/chromium/src/ui/views/controls/prefix_selector.cc?rcl=1466075871&l=18 I'm not sure we want to make any change here, or how we want to handle cross-platform and chrome/blink consistency. (Also need to consider accessibility implications) Alex, can you triage this? (delay ms when typing to select a new combobox/menu/etc. entry)
,
Jun 20 2016
I think hwi@, our A11Y expert, is the right UXer to think about this.
,
Sep 21 2016
Looks like the expert could look at this, but has not done it yet. Or is this handled somewhere else?
,
Aug 25 2017
,
Aug 1
,
Nov 27
***UI Mass Triage *** Adding labels for expert review. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mr.ber...@gmail.com
, Jun 16 2016