Commit Graph

10 Commits

Author SHA1 Message Date
James Teh
0f6fa1755f Bug 1575749: Implement toolbar navigation by typed character. r=Gijs
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
2019-08-30 03:36:53 +00:00
Victor Porof
a3641f184a Bug 1561435 - Format browser/base/, a=automatic-formatting
# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D36041
2019-07-05 09:48:57 +02:00
James Teh
84294a919e Bug 1540918: When a panel is opened from the toolbar via the keyboard, restore focus to the toolbar button when the panel is closed. r=Gijs
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
2019-04-04 17:04:18 +00:00
James Teh
78b51795fb Bug 1539647: Make the "Show more bookmarks" button navigable with the keyboard. r=Gijs
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
2019-03-29 00:46:57 +00:00
Gurzau Raul
705afe79b8 Backed out changeset fae91b8aa3d7 (bug 1539647) for eslint falure at /content/browser-toolbarKeyNav.js on a CLOSED TREE. 2019-03-29 01:51:37 +02:00
James Teh
ba69484a3b Bug 1539647: Make the "Show more bookmarks" button navigable with the keyboard. r=Gijs
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
2019-03-28 23:22:32 +00:00
James Teh
8c36d7798f Bug 1538575: Toolbar keyboard navigation: Make arrow keys behave as expected for RTL locales. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D24841
2019-03-26 10:35:21 +00:00
James Teh
23aa9365d3 Bug 1436086: Implement keyboard navigation for the main and Bookmarks toolbars. r=Gijs
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
2019-02-13 22:51:06 +00:00
Cosmin Sabou
a7e938cadb Backed out changeset a14a11bf2d6f (bug 1436086) for eslint failure on browser_toolbarButtonKeyPress.js. CLOSED TREE 2019-02-13 15:35:34 +02:00
James Teh
b7fb0791a7 Bug 1436086: Implement keyboard navigation for the main and Bookmarks toolbars. r=Gijs
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
2019-02-13 11:18:45 +00:00