When Fission is on, loading a cross-origin iframe triggers process switching when calling the channel::OnStartReqeust.
If a ServiceWorker should intercept the loading, the interception setting is completed while opening the channel.
That means the service worker controls the ClientSource created by the old process.
After process switching completed, the new ClientSource will be created and resume the loading from the opened channel.
However, in the original code, we did not update the controlled Client in the ServiceWorkerManager.
And when loading the same origin subresource in the new process, it makes ServiceWorkerManager cannot find the correct ServiceWorker to perform the interception.
Since we are going to release sw-e10s, this patch is only for both Fission and sw-e10s are on.
Differential Revision: https://phabricator.services.mozilla.com/D49284
--HG--
extra : moz-landing-system : lando
This delays when the DocumentChannelChild is canceled during a process switch to
be after the switch has been completed, to prevent the load event firing too
early in the original content process.
Differential Revision: https://phabricator.services.mozilla.com/D47312
--HG--
extra : moz-landing-system : lando
This delays when the DocumentChannelChild is canceled during a process switch to
be after the switch has been completed, to prevent the load event firing too
early in the original content process.
Differential Revision: https://phabricator.services.mozilla.com/D47312
--HG--
extra : moz-landing-system : lando
This delays when the DocumentChannelChild is canceled during a process switch to
be after the switch has been completed, to prevent the load event firing too
early in the original content process.
Differential Revision: https://phabricator.services.mozilla.com/D47312
--HG--
extra : moz-landing-system : lando
We previously used the initial LoadInfo from when the DocumentChannel was created, but need the one from the most recent channel in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D46741
--HG--
extra : moz-landing-system : lando
We previously used the initial LoadInfo from when the DocumentChannel was created, but need the one from the most recent channel in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D46741
--HG--
extra : moz-landing-system : lando
We previously used the initial LoadInfo from when the DocumentChannel was created, but need the one from the most recent channel in the parent.
Depends on D46740
Differential Revision: https://phabricator.services.mozilla.com/D46741
--HG--
extra : moz-landing-system : lando
Thanks to the promisifying of SendCrossProcessRedirect we no longer needs callback to DocumentChannelParent from nsHttpChannelParent. So we can remove the interface that allowed to do so.
Differential Revision: https://phabricator.services.mozilla.com/D46174
--HG--
rename : netwerk/base/nsICrossProcessSwitchChannel.idl => netwerk/base/nsIProcessSwitchRequestor.idl
extra : moz-landing-system : lando
There's only one consumer of these promises. It doesn't need to be non-exclusive.
Differential Revision: https://phabricator.services.mozilla.com/D46016
--HG--
extra : moz-landing-system : lando
This is a stepped transition ; as SessionStore currently only knows how to deal with nsHttpChannel we have to go through the redirect only if the current channel is a nsHttpChannel.
In a followup change we will allow SessionStore to directly deal with the DocumentParentProcess.
Differential Revision: https://phabricator.services.mozilla.com/D46014
--HG--
extra : moz-landing-system : lando
Thanks to the promisifying of SendCrossProcessRedirect we no longer needs callback to DocumentChannelParent from nsHttpChannelParent. So we can remove the interface that allowed to do so.
Differential Revision: https://phabricator.services.mozilla.com/D46174
--HG--
rename : netwerk/base/nsICrossProcessSwitchChannel.idl => netwerk/base/nsIProcessSwitchRequestor.idl
extra : moz-landing-system : lando
There's only one consumer of these promises. It doesn't need to be non-exclusive.
Differential Revision: https://phabricator.services.mozilla.com/D46016
--HG--
extra : moz-landing-system : lando
This is a stepped transition ; as SessionStore currently only knows how to deal with nsHttpChannel we have to go through the redirect only if the current channel is a nsHttpChannel.
In a followup change we will allow SessionStore to directly deal with the DocumentParentProcess.
Differential Revision: https://phabricator.services.mozilla.com/D46014
--HG--
extra : moz-landing-system : lando
DocumentChannel doesn't use the REDIRECT_INTERNAL flag when replacing itself with a real channel if there has been a real redirect handled in the parent.
This is so that the docshell knows about the URI change, and to add history entries.
The timing data however always wanted to be treated as an internal redirect, so that we don't record a new 'redirectEnd' at the time of the switch.
This adds a new parameter to ConfigureReplacementChannel so that we can more accurately describe the behaviour we need.
Differential Revision: https://phabricator.services.mozilla.com/D45150
--HG--
extra : moz-landing-system : lando
For now, when we turn on `disable cache` switch in DevTools[1], web page loads
the contents without using the cache. Furthermore, DevTools as well comes to
load the contents DevTools inspects without using the cache. And, if the loaded
contents from the web page and DevTools was different, becomes impossible to
inspect the content correctly.
Thus, in order to make DevTools refer the same content the web page loaded,
makes DevTools load the contents inspecting from the cache at first, no matter
if disables the switch or not.
When turns on disable cache in DevTools, `LOAD_BYPASS_CACHE` flag is set into
`loadFlags` in the `docshell`.[2] The other hand, the content DevTools inspects
is loaded from a channel DevTools creates with `LOAD_FROM_CACHE` flag.[3]
However, because this channel is belong to same `loadGroup` of the `docshell`,
`LOAD_BYPASS_CACHE` is inherited and is choosen even if `LOAD_FROM_CACHE` is set.
Thus, in this patch, we introduce an attribute `preferCacheLoadOverBypass`
which raises the priority for `LOAD_FROM_CACHE` above `LOAD_BYPASS_CACHE` and
`LOAD_BYPASS_LOCAL_CACHE`.
[1] https://developer.mozilla.org/en-US/docs/Tools/Settings#Advanced_settings
[2] https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1227
[3] https://searchfox.org/mozilla-central/source/devtools/shared/DevToolsUtils.js#542-544
Differential Revision: https://phabricator.services.mozilla.com/D44626
--HG--
extra : moz-landing-system : lando
So that we can restrict QI(nsIIdentChannel) to nsIHttpChannel and DocumentChannelChild objects only.
Differential Revision: https://phabricator.services.mozilla.com/D44111
MANUAL PUSH: multiple authors stack
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