Once the Awesome Bar starts showing options, tab and shift-tab don't move focus to next or previous UI elements, respectively.
Categories
(Firefox :: Address Bar, defect)
Tracking
()
People
(Reporter: ek_mozfan, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Firefox/60.0
Steps to reproduce:
Start typing in the awesome bar.
Wait for the results list to populate.
Press Tab or Shift-Tab.
Actual results:
If there's only one Awesome Bar suggestion, pressing tab appears to do nothing at all (it rotates focus through a list of 1 element).
If there are multiple Awesome Bar suggestions, the next or previous suggestion is highlighted with each tab or shift-tab press.
Expected results:
The next or previous UI element should have been selected. In my case these are the Find Bar and Current Tab, respectively.
Arrow keys suffice for moving between Awesome Bar suggestions. Tab and Shift-Tab should be reserved for focus transitions. At the very least it should be possible for a user to cause the Awesome Bar to stop consuming the tab events intended for the rest of the UI.
|
||
Updated•6 years ago
|
|
||
Comment 1•6 years ago
|
||
(In reply to ek_mozfan from comment #0)
Arrow keys suffice for moving between Awesome Bar suggestions. Tab and Shift-Tab should be reserved for focus transitions. At the very least it should be possible for a user to cause the Awesome Bar to stop consuming the tab events intended for the rest of the UI.
You can close the awesome bar results by pressing Escape - which will then let you use tab to go onto other elements.
As you've seen, bug 1437524 has some more discussion about the history of this.
Not sure if this is a dupe of that bug or not. Marco knows there history better so I'll leave the triage to him.
|
||
Comment 2•6 years ago
|
||
I think this, as-is, is a wontfix.
The idea is that the Address Bar, when open, traps TAB, and you actually have to exit from this mode to move to the next widget.
If there is only 1 element, ideally we'd like TAB to move to the next results group (one-off buttons for example) anyway.
The TAB behavior will likely change soon in bug 1437524, to exactly move through results group, but to move to the next toolbar widget you'll have to ESC to close the panel. This will be more clearer (visually) if we implement the "mega-bar" UI that Verdi suggested us, where the UI element will be more prominent/detached.
Description
•