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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
The patch moves DeprioritizedLoadRunner handling from top level inner window to top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D54754
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This also converts MaybeCloseWindowHelper, and results in the window close operations being always run in the parent (even without DocumentChannel).
Differential Revision: https://phabricator.services.mozilla.com/D49528
--HG--
extra : moz-landing-system : lando
These methods are only callable from the parent process, so it doesn't make
sense to have the method available driectly on BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D50854
--HG--
extra : moz-landing-system : lando
Also some minor cleanup in nsWindowWatcher, as well as a small fix,
where GetWindowByName forgot to addref its return value (as changed in
Part 1).
Differential Revision: https://phabricator.services.mozilla.com/D48976
--HG--
extra : moz-landing-system : lando