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
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
Fission puts subdocuments (potentially) in separate processes, so we can't
just EnumerateSubDocuments and poke the TimeoutManagers for each one.
Differential Revision: https://phabricator.services.mozilla.com/D56547
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Differential Revision: https://phabricator.services.mozilla.com/D55659
With Fission enabled we do not necessarily have access to the
nsDocShell that holds the top-level browsing context, so the
BrowsingContext is a better place to store information that needs
to be accessible to nested browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D55276
This reference is necessary when sending session storage data for
all browsing context to the parent process. Note that it entails
making SessionStorageManager a cycle collection participant, since
adding this reference creates a cycle.
Depends on D55276
Differential Revision: https://phabricator.services.mozilla.com/D55659
With Fission enabled we do not necessarily have access to the
nsDocShell that holds the top-level browsing context, so the
BrowsingContext is a better place to store information that needs
to be accessible to nested browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D55276
Bug 1534012 added a test for postMessage during load and that revealed that mLoading flag isn't always updated
soon enough, so add BrowsingContext::IsLoading which checks also possible local loading status.
Depends on D54754
Differential Revision: https://phabricator.services.mozilla.com/D54836
If the page has already had same type pending request, then we don't want to send another request. If the page has already got the response from the request, we also don't want to send another request again.
In order to achieve that, we decide to store the request's staus on the top-browsing context to make sure that all media elements in the same browsing context tree can share the same status. Thereforw, we could avoid sending redudant request when there is a pending request, and reuse the previous request's result.
Differential Revision: https://phabricator.services.mozilla.com/D52431
If the page has already had same type pending request, then we don't want to send another request. If the page has already got the response from the request, we also don't want to send another request again.
In order to achieve that, we decide to store the request's staus on the top-browsing context to make sure that all media elements in the same browsing context tree can share the same status. Thereforw, we could avoid sending redudant request when there is a pending request, and reuse the previous request's result.
Differential Revision: https://phabricator.services.mozilla.com/D52431
