... and also store allow-rfc1918 bool locally to remove later accesses
to TRRservice.
MozReview-Commit-ID: KkO4u2N9gfE
--HG--
extra : rebase_source : 2fdfecb127987cdbfdccd0e77f7b4bb65f6f5f5d
When the native resolve needs to run again, the rec->mResolving counter
must not be decreased, as otherwise it triggers an assert when the next
resolve completes.
MozReview-Commit-ID: 3UQGkDSOmGi
--HG--
extra : rebase_source : 1caf047070a95b451acf0ddca6b5986f4e4d7c69
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
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.
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : source : 4ebdab0e332892378558817e30d0138c95199ce5
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
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
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.
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 annotates two SQL statements that are responsible for a large amount of
warning spam due to "suboptimal indexes." Given we no longer wish to update
appcache code we can just disable the warning with a commment instead.
--HG--
extra : rebase_source : 519678e38f69cfa2aab75161a058bcdaf548fad0
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : source : 4ebdab0e332892378558817e30d0138c95199ce5
In the previous code, a race condition could cause us to call SendSetPriority() after calling SendDeleteSelf.
For example:
T1: SendDeleteSelf()
T2: if (!mIPCClosed) SendSetPriority()
T1: mIPCClosed = true
MozReview-Commit-ID: 3XOwCaphb2o
--HG--
extra : rebase_source : 609b9d111d97a8e4a60117dd79ecd741725ec611
