Previously, we sent a command event and a click event.
Normally, the command event executes the action, then the click event closes the menu.
However, in some cases (e.g. the Library button), there is no command event handler and the mousedown event executes the action instead.
Differential Revision: https://phabricator.services.mozilla.com/D29151
--HG--
extra : moz-landing-system : lando
Extension panels contain embedded documents; i.e. a <browser> element.
We want users to be able to tab to these and we want them to be focused automatically if a subview is opened from the keyboard, so treat them as tabbable.
However, once an embedded document is focused, we can't manage keyboard navigation inside it, so don't try.
Previously, we tried, which meant keys were overridden even though they didn't do anything, breaking keyboard navigation in extensions altogether.
Differential Revision: https://phabricator.services.mozilla.com/D28442
--HG--
extra : moz-landing-system : lando
Previously, we sent a command event and a click event.
Normally, the command event executes the action, then the click event closes the menu.
However, in some cases (e.g. the Library button), there is no command event handler and the mousedown event executes the action instead.
Differential Revision: https://phabricator.services.mozilla.com/D29151
--HG--
extra : moz-landing-system : lando
Extension panels contain embedded documents; i.e. a <browser> element.
We want users to be able to tab to these and we want them to be focused automatically if a subview is opened from the keyboard, so treat them as tabbable.
However, once an embedded document is focused, we can't manage keyboard navigation inside it, so don't try.
Previously, we tried, which meant keys were overridden even though they didn't do anything, breaking keyboard navigation in extensions altogether.
Differential Revision: https://phabricator.services.mozilla.com/D28442
--HG--
extra : moz-landing-system : lando
Previously, this code cached a list of controls on first use and used that for navigation.
This refactor addresses several issues:
1. There is now a separate focus order for tab/shift+tab and down/up arrows.
This allows menulists, textboxes, etc. which use the arrow keys themselves to be focused with tab, but skipped with the arrows.
This means the user won't fall into these controls when using the up/down arrow keys and be confused by the subsequent arrowing behaviour.
2. When a menulist, textbox, etc. is focused, the arrow keys, space and enter are now passed to the control.
This is a better fix for handling of the arrow keys by menulists (bug 1522092).
It also fixes left arrow in a textarea moving to the previous view instead of moving the caret (bug 1489874).
3. This improves handling of dynamic updates to the panel.
For example, elements that are initially disabled and enabled later will be navigable.
This is because the next element is determined dynamically by the TreeWalker, rather than using a cached list.
4. The interim fix for bug 1522092 disabled PanelMultiView keyboard navigation.
This caused some regressions, including arrow keys/activation on the Site Identity Report a Problem link (bug 1539976) and some controls not being navigable if the Site Identity panel is opened using the mouse (bug 1539984).
With the above fixes, we can now re-enable PanelMultiView keyboard navigation in the Site identity panel and thus fix these regressions.
5. Previously, PanelMultiView keyboard navigation was disabled in the main toolbar overflow menu.
This is because the search box can be added to the overflow menu, which previously caused problems for the arrow keys.
With the above fixes, we can now safely enable PanelMultiView keyboard navigation in the overflow menu.
6. PanelMultiView keyboard tests have been added.
Previously, we relied on tests specific to various panels to exercise this functionality.
Differential Revision: https://phabricator.services.mozilla.com/D25905
--HG--
extra : moz-landing-system : lando
Previously, this code cached a list of controls on first use and used that for navigation.
This refactor addresses several issues:
1. There is now a separate focus order for tab/shift+tab and down/up arrows.
This allows menulists, textboxes, etc. which use the arrow keys themselves to be focused with tab, but skipped with the arrows.
This means the user won't fall into these controls when using the up/down arrow keys and be confused by the subsequent arrowing behaviour.
2. When a menulist, textbox, etc. is focused, the arrow keys, space and enter are now passed to the control.
This is a better fix for handling of the arrow keys by menulists (bug 1522092).
It also fixes left arrow in a textarea moving to the previous view instead of moving the caret (bug 1489874).
3. This improves handling of dynamic updates to the panel.
For example, elements that are initially disabled and enabled later will be navigable.
This is because the next element is determined dynamically by the TreeWalker, rather than using a cached list.
4. The interim fix for bug 1522092 disabled PanelMultiView keyboard navigation.
This caused some regressions, including arrow keys/activation on the Site Identity Report a Problem link (bug 1539976) and some controls not being navigable if the Site Identity panel is opened using the mouse (bug 1539984).
With the above fixes, we can now re-enable PanelMultiView keyboard navigation in the Site identity panel and thus fix these regressions.
5. Previously, PanelMultiView keyboard navigation was disabled in the main toolbar overflow menu.
This is because the search box can be added to the overflow menu, which previously caused problems for the arrow keys.
With the above fixes, we can now safely enable PanelMultiView keyboard navigation in the overflow menu.
6. PanelMultiView keyboard tests have been added.
Previously, we relied on tests specific to various panels to exercise this functionality.
Differential Revision: https://phabricator.services.mozilla.com/D25905
--HG--
extra : moz-landing-system : lando
PanelMultiView adds the keydown handler on the window so that it handles key presses when a panel appears but doesn't get focus, as happens when a button to open a panel is clicked with the mouse.
However, this means the listener is on an ancestor of the panel, which means that handlers such as ToolbarKeyboardNavigator are deeper in the tree.
Previously, PanelMultiView used a bubbling (default) listener.
This meant that ToolbarKeyboardNavigator handled the event first, causing it to interfere when a panel opened within the toolbar; e.g. the Library menu.
To fix this, use a capturing listener for PanelMultiView so it gets the event first.
Differential Revision: https://phabricator.services.mozilla.com/D24848
--HG--
extra : moz-landing-system : lando
Previously, if the accesskey attribute was missing then the label would reach up
to binding parent to find it's accesskey. In practice, bindings already do
[xbl:inherits=accesskey] to send it down to the label anyway.
The problem with this is that for controls without accesskeys, the attribute doesn't get set,
so the label will access the control from JS. This is fine for XBL, since typically
the label XBL will construct at the same time as the control, but when migrating
to Custom Elements, the label gets connected even when the control is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D12355
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Download items in the Downloads Subview of the Library Panel are implemented using a XBL binding that is associated to a "toolbarbutton" element, but inherits from "button-base" in order to avoid the display="xul:button" of the "toolbarbutton" binding. This is because the item contains an inner button, and using a button CSS frame for the outer element would break hover behavior and mouse events.
This changes the binding so it doesn't use a "toolbarbutton" element, which is a different way to avoid the outer button CSS frame, and eventually allows removing support for the "display" attribute in XBL.
Differential Revision: https://phabricator.services.mozilla.com/D14572
--HG--
extra : rebase_source : e0f907aea98419c6f7ee4b53f645e4cfe0fcdf5a
Previously, if the accesskey attribute was missing then the label would reach up
to binding parent to find it's accesskey. In practice, bindings already do
[xbl:inherits=accesskey] to send it down to the label anyway.
The problem with this is that for controls without accesskeys, the attribute doesn't get set,
so the label will access the control from JS. This is fine for XBL, since typically
the label XBL will construct at the same time as the control, but when migrating
to Custom Elements, the label gets connected even when the control is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D12355
--HG--
extra : moz-landing-system : lando
Previously, we had specific code to do this for the "View site information" button (#identity-box) when activated via the keyboard.
To work well for keyboard and screen reader users, all such popups (e.g. Firefox menu, Page Actions, etc.) should do this.
These are all based on panelMultiView.
The arguments passed to PanelMultiView.openPopup can include the event which triggered the popup.
We now use this to detect keypress events and focus the first item in the panel in that case.
Differential Revision: https://phabricator.services.mozilla.com/D11605
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
The XUL elements were not being created because of the wrong createElement
call.
MozReview-Commit-ID: 54RqUJQAqHq
Differential Revision: https://phabricator.services.mozilla.com/D3998
--HG--
extra : moz-landing-system : lando
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
PanelMultiView has its own concept of "selected", so we should use this rather than move focus
using advanceFocusIntoSubTree.
MozReview-Commit-ID: DW2JqqggLl1
--HG--
extra : rebase_source : ec7a6f83fdda176f3286cf4395dc72de6cad2466
PanelMultiView has specific code to support keyboard navigation.
However, it only includes elements with class subviewbutton, which has visual styling.
Some views have controls which should be included in keyboard navigation, but for which the subviewbutton styling is not appropriate.
Therefore, also include elements with the new class subviewkeynav, which is specific to keyboard navigation and has no visual styling.
MozReview-Commit-ID: 8A5q9nbGpdc
--HG--
extra : rebase_source : 431fd2b1e2926e53002a45c290f9d88e8463c42c
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
* The extension content drives the sizing of the browser and popup that contains it via the Extension:BrowserResized message. The ignoreResizes property throttles/debounces this initially, stashing the dimensions received rather than triggering resize of the popup for every message. When the popup is a subview and fixedWidth, we ignore width but *do* want to use the stashed height value.
* Until the panel is given visibility, it has 0 height, so after setting visibility, wait until the next refresh-driver tick before measuring any header which should get added to the overall view height
MozReview-Commit-ID: AgcruVb9QPA
--HG--
extra : rebase_source : 429503a7d38559cc8670a3205b3290b8e0bbbfa2
This prevents synchronous reflows when opening subviews. This also removes a superfluous invocation of the workaround while the panel is still hidden.
MozReview-Commit-ID: DohLjntVaPU
--HG--
extra : rebase_source : 8cd1b86168aee23d4e75556c2b11baf2c8dd0b9c
Views moved to a different panel and then moved back could be placed after the subviews they give access to, if the other subviews were not moved. The transition would be incorrect when these subviews are opened later.
MozReview-Commit-ID: 6JJa0p0McxL
--HG--
extra : rebase_source : 7e28c0638c46b26c45b1073d8a76173fa75fd5fa
The transition code now returns early if the panel was closed during an "await" statement.
Given that transitions can only be interrupted when closing the panel, and the _cleanupTransitionPhase method handles exclusively state related to the panel rather than the individual views, it is now possible to call the _cleanupTransitionPhase method only when the panel is hidden or at the end of a transition.
MozReview-Commit-ID: GYRKyyhJBPK
--HG--
extra : rebase_source : cd66a1e68d0f6cf0a371d7216d54e7d07b576529
This was added in bug 1354141 and is not needed anymore.
MozReview-Commit-ID: 42oF7LpCa6R
--HG--
extra : rebase_source : cd002b7052d14318efe4ef1ac6cc48fe30467265
The anchor state does not need to be cleaned up synchronously, so we can handle it seperately from the transition state.
MozReview-Commit-ID: 1CBP9OS5WmM
--HG--
extra : rebase_source : 533cee34a8f8e0e4bae00a4ff4eb00b9f330f7c1
We now use the "active" property of views to track whether navigation is possible. This has the advantage of being already handled correctly when views are moved to a different panel, and is in line with the purpose of the "active" state. The note about using the "popupshown" event for navigation has been updated accordingly.
Keyboard navigation is also linked to the "active" property now, so there is no need to track the state of the "_transitioning" property anymore.
Since the goBack and showSubView methods can only be called when the view is active, we don't need to check for attempts to start a transition while the panel is closed anymore.
MozReview-Commit-ID: 3KT3A5EwGFy
--HG--
extra : rebase_source : c338362923a7574210c7329bb84316d549898fdc
This allows the state to be handled correctly when views are moved to a different panel.
The "margin-inline-start" style property on the view stack is also reset unconditionally, allowing less state to be stored in the transition details object.
MozReview-Commit-ID: IpgnYsVvx0w
--HG--
extra : rebase_source : 222a398546da3c142f4051c88f5cf9b4da2b8e98
