Bugzilla

(updated Pascal via IRC so clearing that needinfo)

Perry and I just finished up some good pair rr debugging of his reproduction, although there's more to do still.  (Unfortunately pernos.co would make this much easier but we haven't pursued it yet because we'd expect the test to fail in automation for reasons of not being able to contact the real youtube.com servers.  Now that we have a better understanding of exactly how the test is going wrong we should potentially be able to adapt our existing test to this scenario against beta and get a pernos.co trace.)

For my benefit tomorrow, the current scenario as I understand it is that:
- The "https://youtube.com/" -> "https://www.youtube.com/" redirect is being initially processed in the remoteType="file" content process.  We would expect this to trigger the content process swap before processing the redirect, but it does not.
- The "file" content process is getting to HttpChannelChild::SetupRedirect() and invoking HttpChannelChild::ForceIntercepted(true, false)[1] which marks the redirection for interception post-interception.
- While that redirect is then being processed in the parent, a process swap is triggered.
- So we're ending up with an HttpChannelChild for "https://www.youtube.com" in the remoteType="content" content process, which is what we expect.  But because the channel is marked for post-redirect interception, the redirect does not do the normal redirect thing where it consults the content process, and so ClientChannelHelper::AsyncOnChannelRedirect is definitely not being invoked.  And that's the piece that would clear the client.
- It's also the case that child intercept 100% does not expect the redirect to trigger a process swap.  That wildly violates its understanding of how things work.
- It's possible there are complications related to the fact that there are 2 spots in nsHttpChannel where StartCrossProcessRedirect can be invoked.  (OnStartRequest, and ContinueProcessResponse1 which I believe is post-start-request.)

1: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/netwerk/protocol/http/HttpChannelChild.cpp#1665 but that's trunk code and we're debugging beta, so be aware.

(updated Pascal via IRC so clearing that needinfo)

Perry and I just finished up some good pair rr debugging of his reproduction, although there's more to do still.  (Unfortunately pernos.co would make this much easier but we haven't pursued it yet because we'd expect the test to fail in automation for reasons of not being able to contact the real youtube.com servers.  Now that we have a better understanding of exactly how the test is going wrong we should potentially be able to adapt our existing test to this scenario against beta and get a pernos.co trace.)

For my benefit tomorrow, the current scenario as I understand it is that:
- The "https://youtube.com/" -> "https://www.youtube.com/" redirect is being initially processed in the remoteType="file" content process.  We would expect this to trigger the content process swap before processing the redirect, but it does not.
- The "file" content process is getting to HttpChannelChild::SetupRedirect() and invoking HttpChannelChild::ForceIntercepted(true, false)[1] which marks the redirection for interception post-redirection.
- While that redirect is then being processed in the parent, a process swap is triggered.
- So we're ending up with an HttpChannelChild for "https://www.youtube.com" in the remoteType="content" content process, which is what we expect.  But because the channel is marked for post-redirect interception, the redirect does not do the normal redirect thing where it consults the content process, and so ClientChannelHelper::AsyncOnChannelRedirect is definitely not being invoked.  And that's the piece that would clear the client.
- It's also the case that child intercept 100% does not expect the redirect to trigger a process swap.  That wildly violates its understanding of how things work.
- It's possible there are complications related to the fact that there are 2 spots in nsHttpChannel where StartCrossProcessRedirect can be invoked.  (OnStartRequest, and ContinueProcessResponse1 which I believe is post-start-request.)

1: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/netwerk/protocol/http/HttpChannelChild.cpp#1665 but that's trunk code and we're debugging beta, so be aware.