When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
We used to use nsContentUtils::IsThirdPartyWindowOrChannel() to
determine the third-party channel when annotate the channel in
UrlClassifierCommon. Howeverm This is fission-incompatible. So, we
change it to use AntiTrackingUtils::IsThirdPartyChannel() which is
fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D75187
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
In this patch, we make the UrlClassifierCommon::IsAllowListed() to get
the ContentBlockingAllowListPrincipal from the WindowGlobalParent
instead of from the channel.
Differential Revision: https://phabricator.services.mozilla.com/D66213
--HG--
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
This patch does the followings:
1. Remove NotifyOnContentBlocking in WindowOuter and all the call sites.
This is because all the content blocking event handling is moved to the parent.
2. Replace UrlClassifierCommon::NotifyChannelBlocked with AntiTrackingCommon:::NotifyContentBlockingEventInParent.
This is because we don't need to pass the request to the child anymore, which was implemented in NotifyChannelBlocked previously.
3. Add NotifyContentBlockingEvent* utility functions to AntiTrackingCommon.cpp.
4. Update AntiTrackingCommon::NotifyBlockingDecision, when it is called in the parent,
do not send requests to the child, notify the parent directly
Depends on D56874
Differential Revision: https://phabricator.services.mozilla.com/D56875
--HG--
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
This patch does the followings:
1. Remove NotifyOnContentBlocking in WindowOuter and all the call sites.
This is because all the content blocking event handling is moved to the parent.
2. Replace UrlClassifierCommon::NotifyChannelBlocked with AntiTrackingCommon:::NotifyContentBlockingEventInParent.
This is because we don't need to pass the request to the child anymore, which was implemented in NotifyChannelBlocked previously.
3. Add NotifyContentBlockingEvent* utility functions to AntiTrackingCommon.cpp.
4. Update AntiTrackingCommon::NotifyBlockingDecision, when it is called in the parent,
do not send requests to the child, notify the parent directly
Depends on D56874
Differential Revision: https://phabricator.services.mozilla.com/D56875
--HG--
extra : moz-landing-system : lando
This patch makes the matched info also set into the channels in the
parent process. This info is neeced for the ContentBlocking telemetry
and GeckoView also relies on it.
Differential Revision: https://phabricator.services.mozilla.com/D56748
--HG--
extra : moz-landing-system : lando
We make the OnContentBlockingEvent to be notified in the parent procees
for UrlClassifierCommon. There are two place would trigger this,
UrlClassifierCommon::SetBlockedContent and
UrlClassifierCommon::AnnotateChannel. But we still send to the child
process to notify the content blocking since we need to update the log
in the content process in this stage.
Differential Revision: https://phabricator.services.mozilla.com/D55647
--HG--
extra : moz-landing-system : lando
This patch makes the matched info also set into the channels in the
parent process. This info is neeced for the ContentBlocking telemetry
and GeckoView also relies on it.
Differential Revision: https://phabricator.services.mozilla.com/D56748
--HG--
extra : moz-landing-system : lando
We make the OnContentBlockingEvent to be notified in the parent procees
for UrlClassifierCommon. There are two place would trigger this,
UrlClassifierCommon::SetBlockedContent and
UrlClassifierCommon::AnnotateChannel. But we still send to the child
process to notify the content blocking since we need to update the log
in the content process in this stage.
Differential Revision: https://phabricator.services.mozilla.com/D55647
--HG--
extra : moz-landing-system : lando
