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
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
In all those cases, the current nsISerialEventTarget is either the main thread or the MessageChannel's nsISerialEventTarget (since bug 1634846)
Differential Revision: https://phabricator.services.mozilla.com/D81966
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
nsMIMEInputStream was conditionally serializable depending on the
wrapped stream. In general when a stream needs to be sent over IPC, if
it isn't serializable we send it using
InputStreamHelper::SerializeInputStreamAsPipe. There is no reason to
not branch on the wrapped stream when serializing nsMIMEInputStream
and use that, instead of sending the nsMIMEInputStream itself over a
pipe.
Differential Revision: https://phabricator.services.mozilla.com/D80890
We also need to propagate the IsOnContentBlockingAllowList to the script
generated document. For this kind of document, it won't have the
CookieJarSettings at the first place. It will generate its
CookieJarSettings when someone requests it. And we need to propagate the
flag when generating the CookieJarSettings in this case. Or the script
generated document will have a wrong IsOnContentBlockingAllowList flag.
Differential Revision: https://phabricator.services.mozilla.com/D81727
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
Endpoint would be passed by a series of std::move via
nsHttpChannel -> HttpChannelParent -> HttpBackgroundChannelParent ---> HttpBackgroundChannelChild -> HttpChannelChild
|
|
Resolve promise after successfully send IPC<-/
Differential Revision: https://phabricator.services.mozilla.com/D81274
