- Introduce browser.commands.openShortcutSettings() method that can be
called by extensions to open the shortcuts view in AddonManager. The
extension's own shortcuts card is focused and scrolled into view.
- Add mochitests to verify:
- AddonManager tab is opened or reused if already open when
openShortcutSettings() is called.
- AddonManager view is correctly set to shortcuts when
openShortcutSettings() is called. The extension's own shortcuts card
can be found in the page and is focused.
- openShortcutSettings() works even when commands is an empty object
in the manifest.
- openShortcutSettings() is not available when commands is not defined
in the manifest.
Supersedes https://bugzilla.mozilla.org/attachment.cgi?id=9183595 which
appears to be abandoned.
Differential Revision: https://phabricator.services.mozilla.com/D217920
* In ext-windows.js, set the position and size on creation. This moves
the burden of doing so to widget, and could avoid flickering.
* In browser_ext_windows_size.js, we cope with the fact that on linux
the specified size might be the inner rather than outer size. This
was already the case before, but outer{Width,Height} reported always
the inner size so it was papered.
* In browser_unified_extensions_overflowable_toolbar.js and the
relevant head file, we make the code a bit more reliable. This is all
to workaround a mutter but on automation, where if a window was
already maximized and you request a resize, mutter will (correctly)
restore() the window, but will lose the resize information. This
doesn't happen on newer Mutter versions. Still, it seems easier to
use window.maximize(), etc than manually trying to maximize the
window.
* In head_unified_extensions.js we also remove the code to ensure
stable positions since it was broken (it was checking
win.screen.{top,left}, rather than win.screen{X,Y}). We can always
bring it back fixed if really needed.
Differential Revision: https://phabricator.services.mozilla.com/D234903
I stumbled upon this bug while realizing that some of the math I'm doing
for PiP windows doesn't work at all on Linux (bug 1934760), because
screenX != mozInnerScreenX, even though outerWidth == innerWidth.
I've tested this on X11 and Wayland (plasma and Gnome) with CSD and SSD,
and in general, this is the same thing Windows does, so should be fine.
The basic idea is:
* Keep mBounds being frame manager bounds (so, outer* and screen*),
relative to mShell.
* Keep mClientMargin to translate from mBounds to client bounds.
This is both simpler and makes the math consistent.
Differential Revision: https://phabricator.services.mozilla.com/D230981
This patch modifies SessionStoreInternal.onMoveToNewWindow to raise a more specific error message when
no TabState is found for the tab being moved, and then allows that more specific error message
as an uncaught rejection in browser_ext_tabs_events.js through PromiseTestUtils.allowMatchingRejectionsGlobally.
These changes don't address the underlying issue hit by SessionStoreInternal, but in the short term
it will allow to prevent the high frequency intermittent failure currently hit by the
browser_ext_tabs_events.js (and to keep the existing test coverage which would be lost if we
would instead skip the entire test file to workaround the intermittency).
An inline comment added right above the call to PromiseTestUtils.allowMatchingRejectionsGlobally
includes a mention to Bug 1938594 (a new bug filed under the "Firefox :: Session Restore" bugzilla
component to track additional investigations on the SessionStore/TabStateFlusher side) as a reminder
of the underlying issue (and to remove the workaround when it may not be necessary anymore).
Differential Revision: https://phabricator.services.mozilla.com/D230528
I ended up having to change some of the fundamentals of the popupnotification element because the code relied on being able to inherit inline event handler attributes such as buttoncommand as oncommand on the button element and so on.
The primary user of the popupnotification element seems to be `PopupNotifications`. Following a pre-existing coupling with `PopupNotifications._onCheckboxCommand`, by default all commands/actions will simply call the corresponding `PopupNotifications` handler. However, I found at least one instance in `panelUI.js` that tries to override the command handlers. I solved this by dispatching a custom cancelable event on the popupnotification element.
Differential Revision: https://phabricator.services.mozilla.com/D231927
The source of trouble here is the Web Extension Fallback Document,
which is loaded via the system principal and used by DevTools
as the top level target.
Because of it being system principal, we use the special "devtools loader" for ESM.
This is what cause the exception about the "global" option.
Using global attribute set to contextual fixes this exception.
Because of it being the top level target, we are trying to send the request
from its document. But as it is a system principal, it is ignored by the Network Observer.
So that the resent request is sent, but isn't shown.
Using the currently selected target in Network Command helps circumvent that
by sending the request with a real extension document and the request
is then shown in the network monitor.
But this change also impact web page and browser debugging.
Differential Revision: https://phabricator.services.mozilla.com/D231602
This patches applied tweaks to the CSS rules that are meant to choose the right browserAction
theme icon based on the theme colors.
In addition to that this patch includes a tweak (unrelated to the changes applied to the CSS rules)
to the test that would be hitting a failure if the CSS rules are not applied to the browserAction
toolbar-button as the test cases from this test file expects.
This is currently split out from the parent patch including the rest of the frontend changes
because these rules seems worth an additional close look.
Differential Revision: https://phabricator.services.mozilla.com/D229993
This patches applied tweaks to the CSS rules that are meant to choose the right browserAction
theme icon based on the theme colors.
In addition to that this patch includes a tweak (unrelated to the changes applied to the CSS rules)
to the test that would be hitting a failure if the CSS rules are not applied to the browserAction
toolbar-button as the test cases from this test file expects.
This is currently split out from the parent patch including the rest of the frontend changes
because these rules seems worth an additional close look.
Differential Revision: https://phabricator.services.mozilla.com/D229993
- Add all current globals from _createExtGlobal in .eslintrc.js.
- Remove non-existing globals.
- State the sources of the extension-specific globals in .eslintrc.js.
- Move extension-specific globals from common mobile/shared/ to a deeper
level at mobile/shared/components/extensions/.
- Remove obsolete globals/exported/import-globals-from comments from
various ext-*.js files.
- Fix linting errors in some tests due to use of non-global globals,
that have become apparent due to the corrected linter definitions.
Differential Revision: https://phabricator.services.mozilla.com/D228308
Also move getDuplicateTabsToClose and getAllDuplicateTabsToClose away from essentials at the top, closer to related methods.
Differential Revision: https://phabricator.services.mozilla.com/D226279
* Remove the #titlebar element, and ensure toolbars that comprise the titlebar get a .browser-titlebar class
* Ensure we call TabBarVisibility.update when initializing with verticalTab=true
* Adjust TabBarVisibility logic so we allow for the vertical tabs case
* Give #navigator-toolbar z-index: var(--browser-area-z-index-toolbox) to ensure the urlbar view doesnt get clipped behind the lower elements
Differential Revision: https://phabricator.services.mozilla.com/D222059
* Remove the #titlebar element, and ensure toolbars that comprise the titlebar get a .browser-titlebar class
* Ensure we call TabBarVisibility.update when initializing with verticalTab=true
* Adjust TabBarVisibility logic so we allow for the vertical tabs case
* Give #navigator-toolbar z-index: var(--browser-area-z-index-toolbox) to ensure the urlbar view doesnt get clipped behind the lower elements
Differential Revision: https://phabricator.services.mozilla.com/D222059
