The test would set a timer for 200ms then expect to be called back more than 200ms later (as in 201ms or more)
This change makes sure that we don't fail if the callback comes back exactly 200ms later.
MozReview-Commit-ID: 1OCyO3juAdZ
--HG--
extra : rebase_source : 5e123337f73e6b95f5f0afa7d63604d5558dfd94
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
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
This also introduces a hidden pref to allow server-timing access from
HTTP contexts for the purposes of our xpcshell tests. We'll remove that
once we get h2 (and therefore tls test) support for server-timing
trailers (https://bugzilla.mozilla.org/show_bug.cgi?id=1436601).
This does not reject or otherwise error when receiving server-timing
headers or trailers on non-HTTPS contexts, it just makes it unavailable
outside the channel.
MozReview-Commit-ID: qi4h0VQknE
--HG--
extra : rebase_source : 6e6f139cff04f224878ecbf2bcbc84963221cfb6
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This is necessary before we enable the ESLint rule to require using
ChromeUtils for module imports rather than older methods.
MozReview-Commit-ID: mKqByUS0o2
--HG--
extra : rebase_source : d4b856aac7ff7eddc37cbf591c4e6522c45453e2
extra : histedit_source : 1ca2b6031e480fb44a15991241901224acc9e52f
The test previously only switched off the pref and didn't restore the
old value when done.
--HG--
extra : rebase_source : 87a769b3148f17b74f98c343743039b8d0d265c2
* changes call to use nsIURIMutator.setSpec()
* Add new NS_MutateURI constructor that takes new Mutator object
* Make nsSimpleNestedURI::Mutate() and nsNestedAboutURI::Mutate() return mutable URIs
* Make the finalizers for nsSimpleNestedURI and nsNestedAboutURI make the returned URIs immutable
MozReview-Commit-ID: 1kcv6zMxnv7
--HG--
extra : rebase_source : 99b13e9dbc8eaaa9615843b05e1539e19b527504
Calling SetSpec on an nsIURI object doesn't reinitialize the object, meaning
it's not equivalent with creating a new URI with the same spec. While this
might be counter-intuitive we want to preserve existing behaviour for
the moment.
This change makes BaseURIMutator::InitFromSpec call SetSpec on the existing
cloned URI if available. Otherwise it creates a new one.
MozReview-Commit-ID: LuHVRhBItiP
--HG--
extra : rebase_source : fc7b64d01adcb7f2ac5bbd9cfc16dadb3c4939c9
This test is aimed to check whether the order that http server gets requests is the same as the order in the client's pending queue.
However, even if the transactions are dispatched according to the order in pending queue, it doesn't mean the server can get the request in the same order.
This is because the transaction is really dispatched to a connection when nsHalfOpenSocket::OnOutputStreamReady() is called. The order may not be always the same as the pending queue.
Hence, this patch processes the dummy http request once at the time when the previous request's OnStopRequest() is called. This can force the client dispatch only one transaction at the time and make the behavior of this test more predictable.
--HG--
extra : rebase_source : 5f4631ecabdf1f36352a80fbe1939b54348ab682
In our test script we set the unload handler on the inner iframe earlier than the page is loaded, therefore it pass the origin check since the contentWindow object is for about:blank.
Security error will raise if the OnStartRequest for that iframe is received beforehand.
Use about:blank can guarantee to have same-origin window on the inner iframe.
MozReview-Commit-ID: 8AiwGIfoF4
--HG--
extra : rebase_source : cfad1803a61719470f8240700ac917c4931e3dfe