The tabGroups.onRemoved / onCreated / onMoved event depends on the
isAdoptingGroup / removedByAdoption flags to identify tab groups that are
adopted by another window. Although this flag is set for the
`gBrowser.adoptTabGroup` method, it is not in the
`gBrowser.replaceGroupWithWindow` method, which results in incorrect
events.
This patch fixes the issue by setting the isAdoptingGroup flag in
`gBrowser.replaceGroupWithWindow`.
Differential Revision: https://phabricator.services.mozilla.com/D248327
When an extension does not have the contextMenus or menus permission,
it is not possible to have extension-defined context menus on an
extension's action button. The actionContextMenu() call would never
add menu items in this case.
As the bug report shows, trying to call actionContextMenu() can throw
an error when the ext-menus.js module has not been loaded. To avoid
this error, verify that the extension has the permission to add menus.
Because ext-menus.js is declared with `"events": ["startup"]`, the
module is guaranteed to be loaded if an extension has the permissions.
Differential Revision: https://phabricator.services.mozilla.com/D248154
This patch adds a network.sniff.use_extension pref.
When false, the file extension of a URL will only be used to sniff file://
Differential Revision: https://phabricator.services.mozilla.com/D246585
This patch adds a network.sniff.use_extension pref.
When false, the file extension of a URL will only be used to sniff file://
Differential Revision: https://phabricator.services.mozilla.com/D246585
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
