This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
Exposes a new nsIDocShell API, isForceReloading, to determine if
the loaded document was force-reloaded or not.
It relies on the underlying behaviour of nsDocShell::IsForceReloading(),
which again relies on nsDocShell::IsForceReloadType(mLoadType).
The getter is used in the remote agent to test that
Page.reload({ignoreCache: true}) works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D51435
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
the URL moz://a redirects to mozilla's website, Because it redirects to
https we want to use documentchannel.
Depends on D49100
Differential Revision: https://phabricator.services.mozilla.com/D51227
Any number of outer windows may be attached to a BrowsingContext over its
lifetime. While the BrowsingContext is alive, it's easy to keep track of which
of these is active, and therefore which of its inner windows is active. After
it has been discarded, though, it discards its docShell reference, so all we
can tell about an inner window is whether it is active for its own outer
window, but not whether it should be considered active for its
BrowsingContext.
This patch updates the BrowsingContext detach logic to store a flag on the
current inner window recording that it was active when its BrowsingContext was
detached, and then later checks that flag to determine if it is the current
window for a detached BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D49032
Depends on D49870
We fail coop-sandbox.https.html without this, since the changes in bug 1566868 don't apply to DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D49871
We want this to run in both processes so that we set the cspToInherit on the LoadInfo within the child as well as the parent.
Differential Revision: https://phabricator.services.mozilla.com/D47355
Depends on D49870
We fail coop-sandbox.https.html without this, since the changes in bug 1566868 don't apply to DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D49871
We want this to run in both processes so that we set the cspToInherit on the LoadInfo within the child as well as the parent.
Differential Revision: https://phabricator.services.mozilla.com/D47355
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
When we have a parser-created iframe which starts out in-process, transitions
to remote, and then transitions back to in-process, we create separate
DocShells for the first and last in-process loads. Since both are
network-created, and have the same child index, they both try to add
themselves as children to their parent's SHistory at the same index. And since
the entry for the first DocShell already exists at that index when we try to
add the second, that triggers an assertion.
This isn't really ideal, but it is expected given the current state of session
history under Fission. It should hopefully be solved more gracefully when the
Fission-aware session history rewrite is done, but in the mean time, I think
we should just ignore the conflict, since it's expected.
Differential Revision: https://phabricator.services.mozilla.com/D48437
