Note: only implemented in desktop Firefox. On mobile, the tab groups
feature does not exist, so tabs.onUpdated would never fire. The
mobile-specific tabs.json schema does not declare "properties" filter
either, so there is no place to list the "groupId" filter either.
Differential Revision: https://phabricator.services.mozilla.com/D245264
This patch exposes a groupId field on tabs.Tab objects in extensions.
On mobile (Android), the value is always -1.
On desktop, the value is the numeric representation composed from the
internal ID, which happens to fit in a safe integer. As long as the
browser is not running past year 2255, this works. As a fallback,
when an ID in a different format is encountered, the logic falls back
to returning a new unique ID based on a counter. This ID is then
stored in an internal in-memory map to maintain stable consistency.
Since it is unclear when exactly it is safe to discard this value, this
map is never cleared. This minor memory leak is acceptable because it
does not happen in practice, and even if it does, the number of tab
groups over the lifetime of a Firefox session is not going to reach
excessive values.
Differential Revision: https://phabricator.services.mozilla.com/D245159
When using the tab context menu or drag-dropping tabs to put them into a group, record a metric for the number of tabs added to the group.
Data Science asked us to launch with this metric disabled so that they could control it using server knobs. They expect a high volume of events, so they expect to only enable this metric for some proportion of users.
I converted the existing `TabMove` event derived from `UIEvent` being fired when tabs change their tab index in the tab strip. `UIEvent` doesn't allow for attaching additional context/detail to the event. `TabMove` is now a `CustomEvent` that provides more context about the moved tab and it fires in more cases -- it's possible for the tab index not to change despite the tab having "moved" into/out of a tab group.
This approach would not capture tab movements that occur across multiple frames/event loop iterations.
Differential Revision: https://phabricator.services.mozilla.com/D244616
The TV job failures hit so far seems to be both due to the per-testfile timeout being reached before all tasks
in this test file got a chance to run, and in both cases it was hit in chaos mode and on macOS build.
This patch adds a requestLongerTimeout call to increase the per-testfile timeout, which should give the test file
enough time for passing the TV job even when in macOS builds and chaos mode it may be taking slighly longer.
Differential Revision: https://phabricator.services.mozilla.com/D231423
Since Firefox 136, pickers cannot be opened from non-focused tabs.
Unintentionally, background pages of extensions and devtools pages of
extensions were also affected, because their browsers are embedded in a
hidden XUL window, which is considered not focused.
This patch updates CanonicalBrowsingContext::CanOpenModalPicker to allow
pickers to be opened from specific hidden extension browsers again.
To evaluate the feasibility of enforcing the restriction for hidden
background pages, this patch puts the restriction behind a pref,
enabled by default on Nightly only. If no signs of broken extensions
are reported for a few releases, we can set the pref by default, to
enforce the restriction (and document the change accordingly).
After another few releases we can evaluate whether to enforce the
restriction permanently (effectively removing the exception from
this patch) or to revert the pref.
Differential Revision: https://phabricator.services.mozilla.com/D239046
- 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
