This is a completely redesign based on mconley's idea to use `deck`.
That removes a lot of code and makes things a lot better.
Depends on D163077
Differential Revision: https://phabricator.services.mozilla.com/D162390
It looks like this used to be possible by chance when we didn't check
the event in `togglePanel()`. Now that we do this (to prevent
context-click to open the panel for example), we need to check the event
type and which button or key is clicked/pressed.
Differential Revision: https://phabricator.services.mozilla.com/D163076
Depending on the test chunks on Firefox CI, we might have a test file
executed before this one that resizes the window and does not reset it.
In most cases, this isn't an issue except when we have logic to overflow
extension buttons pinned in the toolbar into the unified extensions
panel. This is what's happening here, at least for some configurations.
By making sure that the window is large enough, we should not have
overflowed extension buttons in the panel anymore. That will make the
test more robust.
Differential Revision: https://phabricator.services.mozilla.com/D162961
We have some internal bookkeeping within OverflowableToolbar to remember the state of things that
have overflowed, like how wide the window needs to be before they can be moved back, etc. When an
item is removed from an overflowable toolbar while overflowed, we update that internal bookkeeping
so that OverflowableToolbar doesn't accidentally try to move those items back into the toolbar
when the window becomes wide enough again.
We've added a new overflow list for extension buttons, but we weren't updating our internal accounting
when items had been overflowed into that list. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D162434
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
