CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
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
Channels loaded by service worker don't have loadcontext, so we don't
apply tracking protection on them.
Depends on D80183
Differential Revision: https://phabricator.services.mozilla.com/D80184
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
Endpoint would be passed by a series of std::move via
nsHttpChannel -> HttpChannelParent -> HttpBackgroundChannelParent ---> HttpBackgroundChannelChild -> HttpChannelChild
|
|
Resolve promise after successfully send IPC<-/
Depends on D81273
Differential Revision: https://phabricator.services.mozilla.com/D81274
This is done by tracking a specific BrowsingContextGroup ID on the
WebExtensionPolicy in the parent process. Whenever a load is done with that
policy, the browsing context is replaced to ensure it is loaded in the correct
BrowsingContextGroup.
This patch also ensures that extension iframes are always loaded in the same
process as their embedder document, even if the frame was previously remote.
Differential Revision: https://phabricator.services.mozilla.com/D80256
The goal with this is to avoid having multiple booleans and other values
computed in arbitrary places and used around the method, and instead pre-compute
common shared information, and group each remoteType special-case together.
Hopefully, this should make it easier to extend the behaviour in
MaybeTriggerProcessSwitch in the future.
Differential Revision: https://phabricator.services.mozilla.com/D80255
Due to a change in timing in this patch, when we reset the confirmation pref
at the end of the test, a TRR request would happen after we changed the prefs
leading to accessing a non-local IP in testing and causing a crash.
This should be gated on being in the correct mode anyway
Depends on D81517
Differential Revision: https://phabricator.services.mozilla.com/D82222
mTRRUsed is a variable that we check to gate several telemetry probes, and to
decide if TRR really failed and we should add a domain to the TRR blocklist.
The problem with setting this too early is that when this is true but we
don't actually send the TRR request, then we will report that we fell back
to Do53 and potentially skip next TRR requests in the future.
The solution here is to only set mTRRUsed if TRRServiceChannel::AsyncOpen
succeeds.
Differential Revision: https://phabricator.services.mozilla.com/D81517
See bug 1599160 comment 43 for an example in the wild (though it has
been fixed since) which prevents us from caching resources
unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D81879
Due to a change in timing in this patch, when we reset the confirmation pref
at the end of the test, a TRR request would happen after we changed the prefs
leading to accessing a non-local IP in testing and causing a crash.
This should be gated on being in the correct mode anyway
Depends on D81517
Differential Revision: https://phabricator.services.mozilla.com/D82222
mTRRUsed is a variable that we check to gate several telemetry probes, and to
decide if TRR really failed and we should add a domain to the TRR blocklist.
The problem with setting this too early is that when this is true but we
don't actually send the TRR request, then we will report that we fell back
to Do53 and potentially skip next TRR requests in the future.
The solution here is to only set mTRRUsed if TRRServiceChannel::AsyncOpen
succeeds.
Differential Revision: https://phabricator.services.mozilla.com/D81517
Matt Woodrow
Nika Layzell
Mihai Alexandru Michis
Junior Hsu
Kershaw Chang
Dimi Lee
julianwels
Bogdan Tara
Kris Maglione
Narcis Beleuzu
Andrea Marchesini
Honza Bambas
Valentin Gosu
Csoregi Natalia
Liang-Heng Chen
Dragana Damjanovic
Christoph Kerschbaumer
Coroiu Cristina
Emilio Cobos Álvarez
Razvan Maries
Sylvestre Ledru