When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
When it's first starting up, when mConfirmationState != CONFIRM_OK
the TRR service is not ready to use.
For TRR_FIRST requests we need to fallback to DNS while the service starts up.
Differential Revision: https://phabricator.services.mozilla.com/D61218
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This patch fixes two issues where we may mistakenly load a TRR record even though the host is part of the excluded-domains list:
1. If a.com is part of the excluded domains, but b.com is not, then when we first resolve b.com using TRR, the server may also push the record for a.com; Previously we didn't check if the pushed record is also excluded, which could lead us to load it from the TRR cache.
2. If b.com is resolved using TRR, but later b.com is added to the excluded-domains list, we may mistakenly load b.com from the TRR cache, even though we should use platform DNS for it.
Differential Revision: https://phabricator.services.mozilla.com/D53354
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This patch adds:
* tests that we restart the TRR connection if it gets abnormally shut down
* a way to terminate the TRR connection when attempting to resolve closeme.com
* makes sure that resolving excluded domains with the DISABLE_TRR flag does
not fail. Before this we would return an error code without checking the
excluded domains first.
Differential Revision: https://phabricator.services.mozilla.com/D35076
--HG--
extra : moz-landing-system : lando
This patch calls NetworkConnectivityService::GetSingleton() on the main thread
and keeps a ref to the service until shutdown.
Even though calling ncs->GetIPv6() off-main-thread is technically a data-race
in practice that's OK because only the simple decision whether to send
AAAA requests is made based on that value, which in itself is an optimization.
I filed bug 1556967 for making the connectivity service thread safe.
Differential Revision: https://phabricator.services.mozilla.com/D33765
--HG--
extra : moz-landing-system : lando
This way we preserve the behaviour of getaddrinfo, where both A and AAAA
responses come back at the same time.
Without this Firefox will always be biased, as the first request will usually
be resolved first. So if we requested IPv4 first, we'd mostly be using IPv4.
If we requested IPv6 first, normally we'll wait for the IPv4 response to come
back too, which is functionally equivalent to the new behaviour.
However, if the pref is set network.trr.early-AAAA;true then we'd use the IPv6
response immediately, possibly leading to a failed request if the IPv6
connection fails before we have an IPv4 address to fall back to.
A test for this patch was added in bug 1542561.
Depends on D33476
Differential Revision: https://phabricator.services.mozilla.com/D33477
--HG--
extra : moz-landing-system : lando
This is an optimization. If we detect that the system can't use the IPv6
address, there's no point in making a request for it.
Depends on D33475
Differential Revision: https://phabricator.services.mozilla.com/D33476
--HG--
extra : moz-landing-system : lando
Normally you wouldn't want localhost or *.local domain to be resolved by a
remote resolver.
This patch makes sure that even if we are in TRR-only mode, we still
successfully resolve the domains specified by network.trr.excluded-domains
using native DNS.
Also fixes bug in TRRService::ReadPrefs where we didn't clear mExcludedDomains
before reading the pref.
Differential Revision: https://phabricator.services.mozilla.com/D24380
--HG--
extra : moz-landing-system : lando
When changing addr_info we didn't always update addr_info_gencnt, so when it the old AddrInfo was freed, even though we lock in nsDNSRecord::GetNextAddr, mIter would still point to the old AddrInfo.
Differential Revision: https://phabricator.services.mozilla.com/D23923
--HG--
extra : moz-landing-system : lando
Mihai Alexandru Michis
Andrea Marchesini
Kershaw Chang
Csoregi Natalia
Sylvestre Ledru
Simon Giesecke
shindli
Eric Rahm
Valentin Gosu
Dragana Damjanovic
Arthur Iakab
Razvan Maries
Dorel Luca
Bogdan Tara
Noemi Erli
Nicholas Nethercote
Honza Bambas
Junior Hsu