The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
There's an infinite loop in this test in some environments, caused by
PanelMultiView's tree walker methods checking for width/height of all
focusable elements. Since the buttons in the test panel have no labels,
and in some conditions have no padding, they have 0 height, causing the
tree walker to fail to find a focusable element. The patch just gives
the buttons labels.
Differential Revision: https://phabricator.services.mozilla.com/D147201
When the tracking protection toast popup closes on a timer, it doesn't
smoothly fade out, because it uses PanelMultiView.hidePopup instead of
panelNode.hidePopup. The static method on PanelMultiView ultimately
calls panelNode.hidePopup, but it doesn't have a parameter for enabling
the animation so it passes nothing to that method. This patch extends
PanelMultiView's hidePopup class methods to add an optional `animate`
parameter, and adds that parameter to the toast popup's hidePopup call.
This should slightly reduce the speed of part of
browser_protectionsUI.js but I don't think it affects any other tests.
Differential Revision: https://phabricator.services.mozilla.com/D146394
This replaces all `instanceof` uses for DOM interfaces, since the operator in priviliged context works same as .isInstance().
Differential Revision: https://phabricator.services.mozilla.com/D141785
This replaces all `instanceof` uses for DOM interfaces, since the operator in priviliged context works same as .isInstance().
Differential Revision: https://phabricator.services.mozilla.com/D141785
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
screenForRect takes screen coordinates (device pixels, for our purpose here).
However screenX / screenY are in CSS pixels, so we need to convert them to the
right coordinate space before looking up the screen.
Differential Revision: https://phabricator.services.mozilla.com/D137895
This matches the current macOS behavior with native context menus.
The issue is that closing the panels causes the destruction of the
menupopup while the activate event hasn't run yet, see comment 9.
Executing the command event synchronously like we do for <button>s is
probably worth it to some extent, though note that on macOS with
non-native menus it'd still need to be async because of the
blinking-before-activation that menuitems have. Gnarly :-(
Of course we always use native menus for context menus so it's not a big
deal, but it still affects the content <select> dropdown, I believe.
So this is the less-invasive change.
Differential Revision: https://phabricator.services.mozilla.com/D134777
This matches the current macOS behavior with native context menus.
The issue is that closing the panels causes the destruction of the
menupopup while the activate event hasn't run yet, see comment 9.
Executing the command event synchronously like we do for <button>s is
probably worth it to some extent, though note that on macOS with
non-native menus it'd still need to be async because of the
blinking-before-activation that menuitems have. Gnarly :-(
Of course we always use native menus for context menus so it's not a big
deal, but it still affects the content <select> dropdown, I believe.
So this is the less-invasive change.
Differential Revision: https://phabricator.services.mozilla.com/D134777
