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
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
A straightforward patch. Since DNS resolution is moved to socket process, we have to add another ipdl to make `nsINativeDNSResolverOverride` work.
Differential Revision: https://phabricator.services.mozilla.com/D78483
While doing the TRR dry run experiment it became apparent that we are issuing
a lot of TRR requests that are causing us to DDOS our TRR provider.
We had a hint that this may only be affecting Windows. Upon inspection of the
code and the APIs we use to measure the performance of each TRR service we
discovered that the codepath that is used to get the TTL for DNS records on
Windows was wrongly exercised for TRR too, causing us to keep repeating a
failing TRR request until success (or until the browser was shut down).
We confirmed this with a unit test and logging.
This patch fixes the condition that caused us to look for failed TRR requests.
We also add a second check that ResolveWithTRRServer calls fail if they also
have the RESOLVE_DISABLE_TRR flag set.
Differential Revision: https://phabricator.services.mozilla.com/D78229
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
This change makes a set of probes keyed. The key is "(default)" if no steering
is currently active, or "(auto-detected)" is the current URL has been set
by steering (autodetection).
Differential Revision: https://phabricator.services.mozilla.com/D77022
This change makes a set of probes keyed. The key is "(default)" if no steering
is currently active, or "(auto-detected)" is the current URL has been set
by steering (autodetection).
Differential Revision: https://phabricator.services.mozilla.com/D77022
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084