When ToolbarKeyboardNavigator initializes, it sets aria-hidden and adds a focus listener on toolbartabstop elements.
This is necessary for proper functionality of toolbar keyboard navigation.
However, widgets can be dynamically added by CustomizableUI after ToolbarKeyboardNavigator initializes.
The search bar is one such widget and it does contain toolbartabstop elements.
We now watch for this and initialize any toolbartabstop elements inside added widgets.
Differential Revision: https://phabricator.services.mozilla.com/D62178
When ToolbarKeyboardNavigator initializes, it sets aria-hidden and adds a focus listener on toolbartabstop elements.
This is necessary for proper functionality of toolbar keyboard navigation.
However, widgets can be dynamically added by CustomizableUI after ToolbarKeyboardNavigator initializes.
The search bar is one such widget and it does contain toolbartabstop elements.
We now watch for this and initialize any toolbartabstop elements inside added widgets.
Differential Revision: https://phabricator.services.mozilla.com/D62178
When focused on a toolbar button, users can now type the first (or first few) characters of another button's name to jump directly to that button.
The search characters are cleared after 1 second or if a non-character key is pressed.
This is similar to the typed character navigation implemented for HTML select controls.
Differential Revision: https://phabricator.services.mozilla.com/D43187
Toolbar buttons are only made focusable when accessed via the keyboard.
As soon as they lose focus, their focusability is removed.
This is done so that clicking them doesn't focus them.
Previously, this meant that if a panel opened, focus couldn't be restored to the button like it should be when the panel was closed, as the button was no longer focusable.
To work around this, use the open="true" attribute set on the button when the panel opens.
If this is detected when the button loses focus, focusability is not removed.
Once focus is restored after the panel closes, things continue as normal.
That is, when the button loses focus for some other reason, its focusability is removed.
Differential Revision: https://phabricator.services.mozilla.com/D26073
When the Bookmarks toolbar overflows, it contains buttons with style visibility: hidden.
ToolbarKeyboardNavigator wasn't checking for this and was trying to focus these buttons, which simply failed.
We now skip over these buttons, which means that the Show more bookmarks button can now be reached.
Differential Revision: https://phabricator.services.mozilla.com/D25180
When the Bookmarks toolbar overflows, it contains buttons with style visibility: hidden.
ToolbarKeyboardNavigator wasn't checking for this and was trying to focus these buttons, which simply failed.
We now skip over these buttons, which means that the Show more bookmarks button can now be reached.
Differential Revision: https://phabricator.services.mozilla.com/D25180
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
Having separate tab stops for every toolbar control results in an unmanageable number of tab stops.
Therefore, we group several buttons under a single tab stop and allow movement between them using left/right arrows.
However, text inputs use the arrow keys for their own purposes, so they need their own tab stop.
There are also groups of buttons before and after the URL bar input which should get their own tab stop.
The subsequent buttons on the toolbar are then another tab stop after that.
Tab stops for groups of buttons are set using the <toolbartabstop/> element.
This element is invisible, but gets included in the tab order.
When one of these gets focus, it redirects focus to the appropriate button.
This avoids the need to continually manage the tabindex of toolbar buttons in response to toolbarchanges.
Navigation to for the View site information button and notification anchors is now managed by this new framework.
As such, they no longer need their own position in the tab order and the CSS has been tweaked accordingly.
For now, this new functionality is behind a pref (browser.toolbars.keyboard_navigation) which is currently disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D15060
