This patch covers multiple cases:
- Pre-existing issue: adoptTabGroup adopts tabs by first moving the tabs
elsewhere, then moving it into a group. When moved into a group,
TabMove is fired, which previously translated to tabs.onMoved. That
would result in too much event noise.
- When tabGroups.move is called, it first adopted the tab group in
another window, and then moved the tab group as a whole. This
results in unnecessary tabs.onMoved events too. The fix is to specify
the desired position at once to adoptTabGroup.
Differential Revision: https://phabricator.services.mozilla.com/D246701
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
