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
This change utilizes components.conf to distinguish between the contract implementations of nsISessionStoreFunctions per platform.
Differential Revision: https://phabricator.services.mozilla.com/D206904
We don't want to start skipping entries just because callers passed in
aRequireUserInteraction, since the feature is not ready and the flag in the
entries might not be correct.
Differential Revision: https://phabricator.services.mozilla.com/D203376
If session history in the parent is enabled then session store only works
correctly if the platform collection code is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D203375
These prefs don't do anything unless browser.sessionstore.platform_collection is
enabled, but we don't need the granularity that they provide. Let's just use
have the one browser.sessionstore.platform_collection pref control everything.
Differential Revision: https://phabricator.services.mozilla.com/D203374
This patch also does some cosmetic changes for when parent controlled
loads should be used, but more importantly introduces the pref
'browser.tabs.documentchannel.speculative-load' with the default value
false.
It turns out that speculatively loading in the parent when a parent
controlled load isn't possible is the cause for performance
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D192489
This patch also does some cosmetic changes for when parent controlled
loads should be used, but more importantly introduces the pref
'browser.tabs.documentchannel.speculative-load' with the default value
false.
It turns out that speculatively loading in the parent when a parent
controlled load isn't possible is the cause for performance
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D192489
This patch also does some cosmetic changes for when parent controlled
loads should be used, but more importantly introduces the pref
'browser.tabs.documentchannel.speculative-load' with the default value
false.
It turns out that speculatively loading in the parent when a parent
controlled load isn't possible is the cause for performance
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D192489
This patch also does some cosmetic changes for when parent controlled
loads should be used, but more importantly introduces the pref
'browser.tabs.documentchannel.speculative-load' with the default value
false.
It turns out that speculatively loading in the parent when a parent
controlled load isn't possible is the cause for performance
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D192489
With non-SHIP Desktop we would propagate the session storage across
process switches using session restore, so the internal propagation was
diabled. However, android's session restore has no handling for session
storage, meaning that all session storage is discarded.
This changes the logic to always use the internal propagation, even when
SHIP is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D188647
