This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This also moves nsDocShell's implementation of nsILoadContext to be based on its
BrowsingContext.
This patch does not, by itself, fix all places which try to mutate
`nsILoadContext`. Those are fixed by the other parts of this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67045
