Bug 1626260 - Stop doing content blocking checks when getting the default referrer policy in content processes. r=dimi,baku,ckerschb

Right now, we do a content blocking check when we get the default
referrer policy. And this could happen even before the channel is
opened. This is undesirable for the ETP fission work since we need
information that is calculated when the channel is opened in the parent
to do a content blocking check.

And we find out that doing a content blocking check here is unnecessary
since the tracking state here is not decided yet since the channel
hasn't been opened. And we will update the referrer policy in the parent
once the tracking state is ready.

So, in this patch, we stop doing the content blocking checks when
getting the default referrer policy in content processes.

Differential Revision: https://phabricator.services.mozilla.com/D70193

--HG--
extra : moz-landing-system : lando
This commit is contained in:
Tim Huang 2020-04-09 06:52:20 +00:00
Родитель 666cd90093
Коммит fea8fbffcd
1 изменённых файлов: 7 добавлений и 1 удалений

Просмотреть файл

@ -198,7 +198,13 @@ ReferrerPolicy ReferrerInfo::GetDefaultReferrerPolicy(nsIHttpChannel* aChannel,
if (!cjs) {
cjs = net::CookieJarSettings::Create();
}
if (cjs->GetRejectThirdPartyContexts()) {
// We only check if the channel is isolated if it's in the parent process
// with the rejection of third party contexts is enabled. We don't need to
// check this in content processes since the tracking state of the channel
// is unknown here and the referrer policy would be updated when the channel
// starts connecting in the parent process.
if (XRE_IsParentProcess() && cjs->GetRejectThirdPartyContexts()) {
uint32_t rejectedReason = 0;
thirdPartyTrackerIsolated = !ContentBlocking::ShouldAllowAccessFor(
aChannel, aURI, &rejectedReason);