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
We want to encourage extension developers to use `browser_specific_settings` instead of `applications`, which will be unsupported in Manifest Version 3+. This patch makes sure test manifests in m-c won't cause any issues in the future.
Depends on D160541
Differential Revision: https://phabricator.services.mozilla.com/D160668
This property, along with the CustomizableUI.isWebExtensionWidget, will make it possible
to distinguish WebExtension-provided widgets without sniffing CSS classes, which is what
we currently do.
In the event that the widget has been destroyed or hasn't yet been created, this will
fallback to looking for the `-browser-action` suffix on the ID. This is mainly for use during
migrations which happen early during CustomizableUI startup, when it's unlikely that the
extensions have finished initializing themselves and creating their widgets yet.
Differential Revision: https://phabricator.services.mozilla.com/D160802
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Depends on D160292
Differential Revision: https://phabricator.services.mozilla.com/D160293
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Differential Revision: https://phabricator.services.mozilla.com/D160293
