The name property that existed back when providers were defined in a JSON blob pref
is no longer included in the Remote Settings provider records. This means that
null-checking the property effectively suppresses the steering feature for our
current Remote Settings config. This patch changes `name` to `id` which RS records
DO include.
Differential Revision: https://phabricator.services.mozilla.com/D127927
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
CLOSED TREE
Ensure we only remove the DoH config update observer once in the connection dialog code.
await resetPrefs when cleaning up in the dialog test - it's an async function.
Don't forget to reset the regional pref in browser_remoteSettings_newProfile.js
Use the new default provider pref in test_trr_confirmation.js
Some of the changes in bug 1626083 result in a more deterministic flow that uncovers a race
and an incorrect underlying assumption in the test.
The underlying assumption is that clearing mode on shutdown is disabled in tests, which is false - it's enabled.
The race is that we assume that the mode is already 0 and try to ensure it doesn't change, whereas it actually
starts empty (undefined) and changes to 0, because of the incorrect underlying assumption.
This mistake only exists in browser_cleanFlow.js, the other tests are correctly waiting for the final TRR mode
without trying to ensure no change.
Differential Revision: https://phabricator.services.mozilla.com/D114592
Some of the changes in bug 1626083 result in a more deterministic flow that uncovers a race
and an incorrect underlying assumption in the test.
The underlying assumption is that clearing mode on shutdown is disabled in tests, which is false - it's enabled.
The race is that we assume that the mode is already 2 and try to ensure it doesn't change, whereas it actually
starts at 0 and changes to 2, because of the incorrect underlying assumption.
This mistake only exists in browser_cleanFlow.js, the other tests are correctly waiting for the final TRR mode
without trying to ensure no change.
Differential Revision: https://phabricator.services.mozilla.com/D114592
This prevents clients on volatile networks from running heuristics repeatedly,
which has two consequences: performance hit due to the DNS lookups performed by
heuristics, as well as flooding telemetry since we record an event each time.
With this patch, when a heuristics run is first triggered, we run it as usual
but start a timer in the background. Any runs triggered before the timer fires
are coalesced into a count. When the timer fires, if the count exceeded a limit,
we restart the timer and also the count. If the count was within the limit, we
run heuristics just once if it was triggered at least once while throttling.
To make this testable deterministically, I had to make a few subtle changes,
e.g. to not await calls to runHeuristics.
I also took the opportunity to replace BrowserTestUtils.waitForCondition with
the more canonical copy that lives in TestUtils, and to put the confirmationNS
pref into the prefs object so it doesn't need to be explicitly cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D110358
- Adds CONFIRM_TRYING_FAILED confirmation state. We use this state when we retry confirmation after confirmation fails.
- Rename CONFIRM_TRYING to CONFIRM_TRYING_OK. We use this state when we try confirmation but no confirmation failure has happened.
- Rename CONFIRM_INIT to CONFIRM_OFF. We use this state whenever there is an event that would disable TRR - such as a TRR mode change.
- Add CONFIRM_DISABLED confirmation state. We use this state in mode3 or when confirmationNS=="skip"
- To potentially allow us to have the same behaviour as after Bug 1689113, specifically the we might be able to report TRRService::Enabled = true when retrying and the state is CONFIRM_TRYING_FAILED we added `network.trr.attempt-when-retrying-confirmation`
- After a large number of TRR failures occurs, we immediately trigger another confirmation and go into CONFIRM_TRYING_OK. This allows us to cope with a temporary increase in network latency that is smaller than 6s.
- We no longer trigger confirmation for nsIRequest::TRR_FIRST_MODE when the resolver mode is not TRR_FIRST. This allows us to simplify the code.
- test_trr_proxy.js now calls trr_test_setup() after it sets up the pac script to avoid confirmation causing non-local connections in tests.
- Moves all the confirmation state handing into HandleConfirmationEvent
Differential Revision: https://phabricator.services.mozilla.com/D107666
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
