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
Cmd or Ctrl + mousewheel on macOS should scroll instead of zooming the page. This new behavior will match Safari and Chrome on macOS and Firefox on Windows.
Cmd or Ctrl + horizontal mousewheel on macOS should scroll horizontally, like Safari and Chrome. The comments here mention a Left swipe+Cmd gesture, but AFAICT that gesture doesn't currently work (on my MacBook Air running macOS 12.6).
1. Set "mousewheel.with_control.action" to 1 (scroll) on macOS.
2. Stop setting "mousewheel.with_meta.action" to 3 (zoom) on macOS because we want the pref's default value 1 (scroll) from modules/libpref/init/all.js.
3. Stop setting "mousewheel.with_meta.action" to 1 (scroll) on Windows because that's pref's default value from modules/libpref/init/all.js.
4. Stop setting "mousewheel.with_control.action" to 3 (zoom) on Windows because that's pref's default value from modules/libpref/init/all.js.
5. Update the browser_mousewheel_zoom.js, browser_ext_mousewheel_zoom.js, and test_wheel_zoom_on_form_controls.html tests to re-enable mouse wheel zoom for macOS. Alternatively, I could change this test to expect scrolling instead of zooming on macOS (different from other platforms), but testing the zooming functionality for regressions seems more important than testing the mouse wheel pref's default value on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D159974
Similar to the Manage/Remove/Report actions in the (context) menu, we
close the unified extensions panel when clicking "Pin to toolbar". This
will also prevent the panel to be empty when there is only one extension
listed and we decide to pin it to the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D162414
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
Long ago, the menu panel in was a customizable area that users could drag things into.
That changed back around 2017 in bug 1354117 when the Photon redesign was built. The
menu panel become a static menu, but we also made it possible to permanently move things
to the overflow panel of the nav-bar.
It looks like we never updated the area type constant from referring to the old menu panel
though, so it's "TYPE_MENU_PANEL", and registering a node for it happens with
registerMenuPanel. This patch changes to constant to TYPE_PANEL and updates the registration
method to registerPanelNode.
I a check around the codebase as well as GitHub looking to see if there were any
system add-ons or experimental WebExtensions that rely on TYPE_MENU_PANEL / registerMenuPanel,
but I couldn't find any.
Differential Revision: https://phabricator.services.mozilla.com/D161078
