It seem that only nsStandardURL and nsSimpleURI (and classes that inherit them) do not have threadsafe refcounting yet.
MozReview-Commit-ID: J8gLoBSPCTl
--HG--
extra : rebase_source : 0e1659c28b18909e31b2e3e74baf74edf1e100c8
* Removes mSpecEncoding since the spec is always ASCII encoded
* nsStandardURL::InitGlobalObjects is now called from nsNetStartup
* Removes prefObserver from nsStandardURL
* mDisplayHost is now initialized every time that we change the hostname
* Adds locking to the gAllURLs list
MozReview-Commit-ID: 93mwECxYxWl
* * *
[mq]: overfix
MozReview-Commit-ID: 98nyTYa5ZeR
--HG--
extra : rebase_source : 82045e10771038d7168d1f235143c24c72dd5a45
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
* blobImpl references are now only kept in nsHostObjectProtocolHandler
* removes nsHostObjectProtocolHandler.idl
* Makes nsHostObjectURI no longer inherit from nsSupportsWeakReference
MozReview-Commit-ID: AC1klrfsMnn
--HG--
extra : rebase_source : 142802f9a6fa6aae5611dccf117d88f96a9985a6
This isn't strictly related, but I ran into it for the nth time while updating
tests, and I got fed up with having my tests fail with a useless numeric value
with no indication of where it came from.
MozReview-Commit-ID: 6OjgVYw7tNd
--HG--
extra : rebase_source : 259667d2a26ec4252a0f8a097ca35b3b702b17a0
extra : histedit_source : 492f541471b896a9a4b941baad2b14de8faf9113
* This is needed in order to make the constructors of URI implementations private
MozReview-Commit-ID: 8dddDXbmrfF
--HG--
extra : rebase_source : b8e471d228617ae4bd07c5ed6317951c06ce8d56
BackgroundFileSaver holds a reference to its nsIBackgroundFileSaverObserver
(observer). If such an observer has an enclosure that captures the
BackgroundFileSaver itself (as in test_backgroundfilesaver.js), this causes a
cycle that won't be caught by the cycle collector. Thus, we have to manually
break the cycle when we're done with the observer (in
BackgroundFileSaver::NotifySaveComplete). Note that this currently relies on the
fact that this implementation requires that Finish always be called (see remarks
in nsIBackgroundFileSaver.idl).
MozReview-Commit-ID: GOO9q2vFRso
--HG--
extra : rebase_source : f62b0ec513e0b681da3e76c0af31077d2fa03fea
extra : amend_source : 2b3a11d4b17df10705bad38e02b6ce130b456448
The initialization path for the SOCKS proxy in firefox involves creating
a generic AF_INET socket, and then replacing it if the actual
configuration requires something else (either AF_INET6 or AF_LOCAL).
With syscall filtering configured to return an error in the event of
AF_INET or AF_INET6 socket creation, this initialization path fails. We
would like this capability so that we can prevent firefox from making
network requests outside of the Tor proxy.
This patch adds a check in the initial socket creation path to see if
the SOCKS proxy host begins with file:// with the assumption that such
URIs point to a UNIX Domain Socket (on Linux+macOS only). In that case,
we create an AF_LOCAL socket rather than the requested type. A similar
check for Windows already exists to determine if the proxy is actually a
named pipe.
In the subsequent replacing step no work occurs as the passed in socket
matches the type we need, so no changes need to be made there.
NOTE: With this change there is still a one-time request for an AF_INET6
socket that occurs. This code path exists to determine whether the
system supports IPv6; if socket(AF_INET6...) fails then it is assumed
that the system does not. However, this check only affects code that is
unreachable when using AF_LOCAL sockets so it seems safe leave as it is.
However, this does mean that firefox will still be incompatible with
seccomp policies which kill the calling thread in the event of a
socket(AF_INET6,...) call.
... as they otherwise appear in the about:networking list as "false"
while having been resolved by TRR.
MozReview-Commit-ID: 9g9fUExvyjS
--HG--
extra : rebase_source : 3098b7c3f7d01e55f5a8c031fc6a73e53f7edb05
... to avoid a catch-22 as CP needs name resolve to work.
MozReview-Commit-ID: DC1CjlUy4cJ
--HG--
extra : rebase_source : 3bc0f146071f04757d44b76f352e48b2abb4dad0
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
These are the only occurrences of "browser.cache.use_new_backend" in the tree.
MozReview-Commit-ID: IOSw0uUD5FW
--HG--
extra : rebase_source : c6c7e6abfdf2c3ff23c1f18e36110781f6b5580b
The original code (from bug 1200802) declared an XPCOM object as a static bare
pointer, which for future reference is probably never the right thing to do. It
might have worked if it was cleared before shutdown but it never was.
MozReview-Commit-ID: EMe7wgzm6zv
--HG--
extra : rebase_source : 572ce6822e297692bab3311a65e1143785b913c4
Previously it would store the time even for early AAAA responses that
weren't used until the A response came in, thus getting the timing
wrong.
MozReview-Commit-ID: KctUjMjH5FR
--HG--
extra : rebase_source : fafd7ad25cd1b7a43d4b4a5653600cad830b471d
To prevent it from sitting waiting for an event that was sent before the
TRRService started.
MozReview-Commit-ID: 9F0IlWGdA9O
--HG--
extra : rebase_source : 6a70210a4e538d8a1b240684a0b3ed5fed38e6ad
