This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This patch persists the CrossOriginEmbedderPolicy on the Document and
WindowContext.
The WindowContext's embedder policy is set in
WindowGlobalActor::BaseInitializer by either adopting the policy of the HTTP
channel that loaded the document, or in WindowGlobalChild::OnNewDocument
by inheriting the one from the browsingContext's windowContext.
Differential Revision: https://phabricator.services.mozilla.com/D46903
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
There are various times when it would be useful to get the toplevel or parent
WindowContext from a window or browsing context. While this is already possible,
it's currently somewhat inconvenient.
Differential Revision: https://phabricator.services.mozilla.com/D73500
Both the deprecated `Screen.lockOrientation` and replacement
`ScreenOrientation.lock` APIs have been updated to make use of a new
`OrientationLock` field on the `BrowsingContext`. This replaces the
storage and use of APIs for this on the root docshell.
In the non fission case things should behave the same, as pending
promises for previous calls to `Screen.lockOrientation` will still be
cancelled in process. If there are `BrowsingContext`s in other
processes though, IPC will be sent to the parent, and then each other
child to cancel them. This should be spec compliant as the spec is
already racy with regards to multiple `lockOrientation` calls.
This new implementation has a little extra IPC than the optimal
implementation would since the root `BrowsingContext`s
`OrientationLock` is set using the normal `SyncedContext` machinery,
rather than combining the `AbortOtherOrientationPendingPromises`
message for a single message.
This commit fixes both Bug 1597413 and Bug 1597443.
Differential Revision: https://phabricator.services.mozilla.com/D70416
In BrowsingContext::SetDocShell(), we indicate that any remote outer window
proxies need to be cleaned up, if we've transitioned from a remote window
proxy to a local one. However, we don't actually do the cleanup until
nsGlobalWindowOuter::SetNewDocument(), so don't assert if we find remote
window proxies when we're in between these two periods.
Also includes a formatting fix by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D72251
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
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
