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
After bug 1582832, DocShell destruction and BrowsingContext detaching happen
in separate operations, leaving a gap where a DocShell has been destroyed, but
its BrowsingContext is still considered attached. During this gap, the usual
invariant that an in-process, attached BrowsingContext always has an
associated DOM window doesn't hold, nor do the usual invariants for outer
window forwarding security checks.
This patch fixes the detach timing so that a child BrowsingContext for a frame
which has been removed is always marked detached at the same time its DocShell
is destroyed.
Co-authored-by: Kris Maglione <maglione.k@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D62791
These serializers have been superceded by the new
MaybeDiscarded<BrowsingContext> and MaybeDiscarded<WindowContext> serializers
added in earlier parts.
Differential Revision: https://phabricator.services.mozilla.com/D62838
Adds a new MaybeDiscarded wrapper type which allows sending a maybe-discarded
BrowsingContext over IPC to another process which must be explicitly checked for
nullness and discarded status before being used.
Differential Revision: https://phabricator.services.mozilla.com/D62832
There are cases where the initial BrowsingContext that we create for a
FrameLoader will never have a DocShell created for it. In the particular case
when the frame it belongs to is part of an inactive document, trying to
eagerly attach the BrowsingContext ends up attaching it as an active child of
its parent BrowsingContext, when it should be either cached or detached. Which
causes no end of problems.
This patch delays attaching the BrowsingContext until the FrameLoader is
initialized, which solves most of these problems.
Differential Revision: https://phabricator.services.mozilla.com/D59009
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
We go to great lengths to try to avoid initializing FrameLoaders during
document updates. That means that when `BindToTree` is called, the element's
FrameLoader is not initialized, and it has no BrowsingContext. Calling
`GetBrowsingContext()` (which happens as a side-effect of
`HTMLIFrameElement::RefreshFeaturePolicy`), however, forces eager
initialization, which can cause any number of problems.
This patch moves that logic from being triggered by `BindToTree` to being
triggered by `BrowsingContext::Embed`, which happens as soon as the
BrowsingContext is bound to the element, but does not force it to be created
early.
Differential Revision: https://phabricator.services.mozilla.com/D55872
As each media controller corresponds to a tab (a browsing context tree), so the controller's life cycle should be equal to the tab. Currently we use the top-level browsing context to represent a tab, so when that browsing context is being destroyed, we should also destroy the corresponding media controller.
Therefore, `MediaControlService` don't need to have methods to access media controller anymore, we should access media controller directly from the top-level canonical browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D58591
Depends on D47963
This workaround was only used by DevTools when using a chrome frame. DevTools toolbox now always uses frame type=content, so the workaround can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D47964
1. Rename mCallerDocumentURI field of PostMessageEvent to mCallerURI as we
might not always have a document, e.g. when we have a sandbox.
2. When we neither have caller's inner window (and thus we have no caller's
window ID) nor caller's URI, use script location as a source name for the error
object when reporting errors to console.
3. When the caller of postMessage has its window in a different process, pass along
the caller's window ID so that the error can be reported correctly.
Differential Revision: https://phabricator.services.mozilla.com/D59526
