Bugzilla

I think we may have identified the source of the problem in the Serviceworker e10s refactor work.  We're still investigating the problem, but in short:
- The "process switch" mechanism migrates a channel from process A to process B when crossing origins.  Code in SessionStore.jsm[1] makes this decision.
- As a result, the HttpChannelParent/Child pair is migrated to a new process.  At least for normal HTTP(S) redirects, this occurs during nsHttpChannel::OnStartRequest when the headers are first received, with the migration happening before the channel resumes processing and actually will process the HTTP(S) redirect.
- The ClientChannelHelper is attached in the child (by the docshell) and listens to redirects, where it decides to clear the controller from the loadinfo[2] when redirecting off of the original document.
- There appears to be a race related to the migrated HttpChannelChild in the target process being attached to the docshell and having the ClientChannelHelper be able to hear the processing of the redirect.  (The channel's resumption in the parent is not strictly coupled to the child channel being linked t a docshell via a call to `resumeDreictedLoad`[3].)

We expect to have this figured out in the next few days and will move this bug to the ServiceWorkers component and/or dupe as appropriate.

That said, if the webextensions team can shed any insight on how they think this might affect process swap timing or how webextensions might complicate the process swap mechanisms, it would be appreciated, as we'd like to make sure we have test coverage for this fix and are unlikely to be able to generate webextension test cases on our own.

1: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/components/sessionstore/SessionStore.jsm#2317
2: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/dom/clients/manager/ClientChannelHelper.cpp#142
3: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/components/sessionstore/ContentRestore.jsm#188

I think we may have identified the source of the problem in the Serviceworker e10s refactor work.  We're still investigating the problem, but in short:
- The "process switch" mechanism migrates a channel from process A to process B when crossing origins.  Code in SessionStore.jsm[1] makes this decision.
- As a result, the HttpChannelParent/Child pair is migrated to a new process.  At least for normal HTTP(S) redirects, this occurs during nsHttpChannel::OnStartRequest when the headers are first received, with the migration happening before the channel resumes processing and actually will process the HTTP(S) redirect.
- The ClientChannelHelper is attached in the child (by the docshell) and listens to redirects, where it decides to clear the controller from the loadinfo[2] when redirecting off of the original document.
- There appears to be a race related to the migrated HttpChannelChild in the target process being attached to the docshell and having the ClientChannelHelper be able to hear the processing of the redirect.  (The channel's resumption in the parent is not strictly coupled to the child channel being linked to a docshell via a call to `resumeRedirectedLoad`[3].)

We expect to have this figured out in the next few days and will move this bug to the ServiceWorkers component and/or dupe as appropriate.

That said, if the webextensions team can shed any insight on how they think this might affect process swap timing or how webextensions might complicate the process swap mechanisms, it would be appreciated, as we'd like to make sure we have test coverage for this fix and are unlikely to be able to generate webextension test cases on our own.

1: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/components/sessionstore/SessionStore.jsm#2317
2: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/dom/clients/manager/ClientChannelHelper.cpp#142
3: https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/browser/components/sessionstore/ContentRestore.jsm#188