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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
BrowsingContext.findWithName is required to do access checks based on the
requestor, which can only be done in the process which owns it. This change
also alters the behavior of the existing CanAccess origin checks, which
typically treat any item as same-origin, but only when the docshells are
actually same process.
Removing the exemption fixes the behavior discrepancy between Fission and
non-Fission runs, but also requires that the test be updated to expect proper
access checks. Which is the situation we really want to test, anyway.
Differential Revision: https://phabricator.services.mozilla.com/D45837
--HG--
extra : moz-landing-system : lando
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
