At least on a Macintosh, the behavior when typing in a listbox (such as the Component list on the Browser bug entry page) is not as expected. (Note that when I say 'letter' below I mean any character that can be typed.) A) Typing in a letter goes to the first following option starting with that letter, instead of the first occuring option. For example: in the Component listbox, select 'Bookmarks' by clicking on it. Type 'B'. Result: 'Browser-General', the next in the list, is selected. Expected behavior: 'BiDi Hebrew & Arabic', the first 'B' in the list, is selected. B) Typing in a letter for which no option begins does nothing, instead of moving to the closest option. For example: in the Component listbox, select 'Bookmarks' by clicking on it. Type 'A'. Result: nothing. Expected behavior: 'BiDi Hebrew & Arabic', the first 'B' in the list (as there are no 'A's), is selected. Similarly if 'Z' is typed, 'XSLT', the last option in the list, as there are no 'Z's, should be selected. Also, if 'G' is typed, 'Help' should be selected, as it is the first option following 'G' in the list. (Order of rules for expected behavior:) 1. If any options begin with letter typed, move to the first such option 2. Else, if any options begin with a letter following the one typed, move to the first such option 3. Else, move to the last option on the list. C) A series of letters typed to move within the list is treated as separate commands, instead of as a group. To reproduce: 1. Type "bo" with normal typing speed Result: 1. 'Bidi Hebrew & Arabic' is selected when 'b' is typed, 2. 'OJI' is selected when 'o' is typed. Expected result: 1. 'BiDi Hebrew & Arabic' is selected when 'b' is typed, 2. 'Bookmarks' is selected when 'o' is typed. I believe the mac considers a series of letters typed in to be a single string unless there is a pause of about a second between the letter entry. It may be related to the repeat delay rate which is a control panel/system pref option.
Oops, when doing the testing accidentally set this to OJI. Sorry.
Component: OJI → HTML Form Controls
I am not a qa contact for HTML form controls. Reassign.
Assignee: joe.chou → rods
QA Contact: pmac → madhur
Confirming that keypresses in listboxes don't work unless an item exists that starts with the letter that was pressed. If no item is found that starts with the letter that was pressed, the next nearest item alphabetically should be selected. Revising Summary.
*** Bug 140211 has been marked as a duplicate of this bug. ***
I suggest implementing this XP, not just on OSX
Adding "pulldown" to summary, as pulldown menus should also be able to handle the correct typing (bug 140211).
OS: MacOS X → AIX
Summary: Improve guess logic when keypress occurs in listbox → Improve guess logic when keypress occurs in listbox/pulldown
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 142372 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
I've thought about this... and what does "alphabetically" mean, exactly? What if my listbox and keyboard are both Chinese? What if they're Spanish (the alphabetical order is a bit different from English)? Issue (C) in comment 0 is now resolved. Issue (B) is not resolvable, in my opinion. Issue (A) is invalid, since the idea is that multiple presses of "b" would move amongst the options starting with "b" in order. Marking WONTFIX (for the (B) and (A) issues, since (C) is covered by a separate FIXED bug).
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Component: Layout: Form Controls → Image: GFX
Resolution: --- → WONTFIX
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.