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
