This is more complex than merely modifying NS_GetDefaultReferrerPolicy()
because at the time most (all?) callers call nsIHttpChannel::SetReferrer/
nsIHttpChannel::SetReferrerWithPolicy before the channel is opened,
which means we won't know whether the channel is a tracking resource or
not yet. So we would need to re-evaluate this decision after that
information becomes available. For that, we need to remember the
original URI argument passed to these functions since that information
is currently destroyed and isn't persisted anywhere in the system.
Differential Revision: https://phabricator.services.mozilla.com/D20901
--HG--
extra : moz-landing-system : lando
- Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent
Differential Revision: https://phabricator.services.mozilla.com/D18391
--HG--
extra : moz-landing-system : lando
- Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent
Differential Revision: https://phabricator.services.mozilla.com/D18391
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
- Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent
Differential Revision: https://phabricator.services.mozilla.com/D18391
--HG--
extra : moz-landing-system : lando
With the old process selector service implementation, non-cached loads
would skip the call into the process selector.
This implementation piggybacks atop the existing 'redirectTo' mechanism.
This is unfortunately not the perfect system for catching these loads,
as it doesn't provide an opportunity for performing a final process
switch before redirecting to a non-http channel. In addition, it doesn't
provide indication that a redirect is going to happen, causing
potentially unnecessary process switches.
Not all places where 'redirectTo' is supported use this mechanism. This
process switching mechanism is only checked in situations after
http-on-examine-response.
Potential future changes include:
1. Moving these checks closer to the real 'OnStartRequest' call (e.g.
in ContinueProcessNormal + ContinueOnStartRequest3). This would mean
that loads other than the final load will not cause process swaps.
2. Adding a callback before a redirect is performed, passing in the new
channel, and allowing modifications to be made. This would allow
performing a process swap before redirecting to a non-http(s)
channel.
Depends on D15609
Differential Revision: https://phabricator.services.mozilla.com/D15610
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Since we need the loadInfo to set up the IPDL connection, we move the logic to
do so from HttpChannelChild::AsyncOpen to HttpChannelChild::SetLoadInfo
via InitIPCChannel.
It would have been nicer to do so in HttpChannelChild::Init, but
I ran into issues with view-source channels, which required an ugly hack.
Also note that RemoteChannelExists() preserves the existing contract - it is
true between asyncOpen and onStopRequest - but the name is slightly off, as
the channel has already been open by the time we call asyncOpen. We will fix
this in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D12419
--HG--
extra : moz-landing-system : lando
