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
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
- This patch makes sure that we don't create nsDNSService on both child process and middleman process.
- gNeckoChild won't be created in middleman process, so it's fine to create ChildDNSService on middleman process.
- Add some MOZ_DIAGNOSTIC_ASSERT in TRR, so we know where TRR is used on child process.
Differential Revision: https://phabricator.services.mozilla.com/D40018
--HG--
extra : moz-landing-system : lando
From the log, I found that the intermittent crash happened because SocketProcessBridgeParent's message loop is destroyed before the IPC channel is closed. Before this patch, the only way to close the IPC channel between SocketProcessBridgeParent and SocketProcessBridgeChild is relying on "content-child-shutdown" notification in child process. If socket process gets terminated before "content-child-shutdown", the IPC channel is never closed.
So, this patch tries to close the IPC channel at SocketProcessChild::CleanUp if the channel is not closed.
Differential Revision: https://phabricator.services.mozilla.com/D38287
--HG--
extra : moz-landing-system : lando
