Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
This patch does the following:
1. Introduce a new log module "nsChannelClassifierLeak" for less
important debug message
2. Sync the format of debug message - "ClassName::FunctionName - description [this]"
3. Print uri and top-level uri in the entry point of
AsyncChannelClassifier, remove logging uri in some functions
Differential Revision: https://phabricator.services.mozilla.com/D83610
This patch does the following:
1. Introduce a new log module "nsChannelClassifierLeak" for less
important debug message
2. Sync the format of debug message - "ClassName::FunctionName - description [this]"
3. Print uri and top-level uri in the entry point of
AsyncChannelClassifier, remove logging uri in some functions
Differential Revision: https://phabricator.services.mozilla.com/D83610
ShouldEnableClassifier checks two things:
1. If AddOn can load the channel
2. If the classified channel is top-level.
For the first point, we added the check in Bug 1308640, and I think the
idea is only for tracking protection to not block channels when
extensions have permission on the channels' domain.
For annotation features, we should always annotate a channel regardless of whether
it is controlled by extensions (also for ETP).
And since we use first-party classification flag in channels, so we
should also annotate channel no matter it is top-level, first-party or
third-party.
So this patch removes calling ShouldEnableClassifier in annotation
features and also rename ShouldEnableClassifier to
ShouldEnableProtectionForChannel to make the idea more clear.
Differential Revision: https://phabricator.services.mozilla.com/D82504
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
