Ensuring that the date input within a main browser is not loosing focus when its associate date picker panel is opened and that the focus is udpated accordingly when it is closed (main part of the patch was crafted by Emilio, tests are added by ayeddi).
Differential Revision: https://phabricator.services.mozilla.com/D167698
For `<input type=date>` and `<input type=datetime-local>`, when a month-year selection dialog is opened from the datepicker/calendar dialog, `Escape` now would only close the month-year selection panel and would keep the datepicker open, returning the focus to the focusable day/gridcell on the calendar grid.
Differential Revision: https://phabricator.services.mozilla.com/D165117
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
Done:
- Provide the [ARIA Date picker dialog](https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html) keyboard navigation pattern
- Manage tab order of a daysView to prevent keyboard trap within a datepicker dialog
- Update default behavior on Datepicker's `this._closePopup()` method
- Spinner styling updated to provide appropriate focus indication when navigating with a keyboard
- Added functional and markup tests to ensure keyboard navigation is supported as expected, split existent datepicker tests to avoid test timeouts and provide better grouping and readability
Depends on D141175
Differential Revision: https://phabricator.services.mozilla.com/D142743
This will force the panel to close when we click an item in the context
menu, without having to handle each menu item separately.
Differential Revision: https://phabricator.services.mozilla.com/D162424
I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...
In any case while going through the code the status panel can be
simplified a bit now, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D156876
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
The copy guidance recommends adding an ellipsis to the end of labels for
controls that require an additional step to complete the action
specified by the label. We have some menuitems and panel buttons that
open a bookmark dialog or the edit bookmark panel that don't have an
ellipsis, so add that. Also, the form "Bookmark this x" has been changed
to "Bookmark x" in menuitems. Also, there's a "Print Selection" menuitem
that needed an ellipsis. Thanks for the review!
Differential Revision: https://phabricator.services.mozilla.com/D154320
I noticed some missing context menu style when loading the context menu
from our own viewcache, which explains the difference between primary
and secondary button click. Not sure ecavtly what was missing as the
styles are all over the place.
The menu item actually works, the actions are called and for
checkbox-like menu items, the `checked` attribute is correctly set in
the "HTML". Also it looked like sub-menus weren't affected (e.g. Tree
Style Tab didn't have any issue).
While investigating, I also noticed that most (if not all) `menupopup`
elements are declared in the main popupset, so I tried to move the
unified extensions context menu to this main popupset and lazy-load the
l10n strings (similar to the toolbar context menu [1]).
That fixed the bug.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1609556
Differential Revision: https://phabricator.services.mozilla.com/D153330
Add an "Open in New Container Tab" menu to the Synced Tabs sidebar
context menu, to match similar menus elsewhere in tab menus.
Differential Revision: https://phabricator.services.mozilla.com/D151777
Replace some fluent strings that cover the same ground as existing
strings that see more use. This will make the (English) diction more
consistent between the context menus.
Differential Revision: https://phabricator.services.mozilla.com/D151775
This removes HTMLMenuItemElement and all the code and tests preffed off
by dom.menuitem.enabled.
The HTML parser changes are the result of applying the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D149979
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
