This adds support for the Origin-Agent-Cluster header. A map from principals to
their cached origin-agent-cluster status is maintained in the
BrowsingContextGroup, and synchronized to child processes such that it can be
used to create DocGroups.
Note that this patch does not implement origin-keyed process isolation for
Fission. Fission process isolation still always uses the site-origin.
It's likely we'll want to implement additional hereustics and/or tracking to
decide when to perform origin-keyed process isolation to avoid potential
process count increases when the default is changed to origin-isolated.
Differential Revision: https://phabricator.services.mozilla.com/D236974
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
Your patch looks good to me. Not sure if there's a non-racy way of
testing the internal full-zoom value here...
But in general, assuming consistent zoom lacking other sources of
information seems like the right thing to do.
I agree that eventually we want to probably move the site-specific zoom
impl into Gecko (if only because Android is also going to want that, see
bug 1547181, where I added a comment).
Co-authored-by: Nika Layzell <nika@thelayzells.com>
Differential Revision: https://phabricator.services.mozilla.com/D220277
This patch removes test_iframe.html. We remove it because the newly introduced test covers the tests done in that test. The reason for removing it in the first place is now that screen properties are inherited/spoofed xorigin, we get a 4px difference. The reasosn for 4px difference is the test runner runs tests in an iframe with a 2px border on each side.
Differential Revision: https://phabricator.services.mozilla.com/D215509
Previously it was possible to bypass specific BCG selection based on
cross-origin isolated status if the site was allowed to load file URIs
using enterprise policies, which could lead to a crash.
This patch changes the behaviour such that BCG selection now happens
correctly. The site will still not be cross-origin isolated due to being
loaded into a file content process.
Differential Revision: https://phabricator.services.mozilla.com/D217007
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
