mCleanedUp is a VarCache variable, which mirrors the canonical value of the
network.predictor.cleaned-up pref. When the canonical pref value is modified,
e.g. by SetBool(), then mCleanedUp is also updated.
But the updating relationship is one-way -- if mCleanedUp is modified, the
canonical value of the pref is not updated. Such an inconsistency is bad! For
example, Predictor.cpp will use mCleanedUp's value, but about:config will show
the canonical value.
(For this reason, VarCache prefs are meant to be read-only outside of libpref.
Bug 1436655 will enforce this.)
This patch changes mCleanedUp so it's not a VarCache variable, avoiding the
mirroring issue.
MozReview-Commit-ID: LIG02gMkRjF
--HG--
extra : rebase_source : 273b2372ce718b0f346695a0dc96a189cd3ba233
Otherwise it will just load back the same (problematic) addresses from the
cache again the second time. This introduces a new resolver bit
(REFRESH_CACHE) that also invalidates the existing cache entry while doing the
new resolve.
MozReview-Commit-ID: 5Bc2KiAGYYA
--HG--
extra : rebase_source : ae368c88a5db27f0980b9928439d27588bc84815
WebPlatformTests expect that when calling
url.host = "host:" // port missing
url.host = "host:65536" // port too big
url.host = "host:bla" // invalid port
that the hostname will be set, but the port will be left unchanged.
Since DOM APIs are the only consumers for SetHostPort it means we can change this behaviour to match the WPT expectations.
As such, SetHostPort will return NS_OK if setting the host succeded, and will ignore if setting the port failed.
MozReview-Commit-ID: LoMw8hCWlCv
--HG--
extra : rebase_source : db28b73d98060c2f66f899afe1a4ae26f4db85db
We normally fail in nsStandardURL::SetPassword if the username is empty.
But if the password we are trying to set is also empty, we should't really fail.
MozReview-Commit-ID: FIDqkPrb1gp
--HG--
extra : rebase_source : 9080c44e91e27acd210f3ace3a234528513928c3
Calling NS_ENSURE_SUCCESS at the begining of the methods shows the error in the console, but what we really care about is where the error code comes from. So it is best to use if (NS_FAILED(mStatus) {} at the begining of the methods, and NS_ENSURE_SUCCESS right after calling the appropriate method on mMutator.
MozReview-Commit-ID: 5vVuHk3N4FU
--HG--
extra : rebase_source : f477f0f87b3303422a595f27d9b39ac25335d701
* Removes setHostAndPort from nsIURIMutator as it only has one use
* Instead, the consumer sets the port to -1 before calling setHostPort()
MozReview-Commit-ID: Jx9UMW440hq
--HG--
extra : rebase_source : cb60e76c905db6bb308ddfd8fa548cc13d3afe06
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
nsBase64Encoder::Finish currently works by calling PL_Base64Encode to
allocate a base64-encoded string, then Assign()'ing that to the result
string, another allocation. mozilla::Base64Encode enables us to base64
encode directly into the result string with a single allocation, saving
an allocation. (Base64Encode is also slightly more efficient, because
we don't have to do a strlen() on the string being Assign()'d.) Let's
use Base64Encode instead.
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
This macro is identical to NS_INTERFACE_MAP_END and encourages the
reader to think that there's something extra-special threadsafe about QI
implementations that use the macro, when in reality there's nothing of
the sort.