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 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
* 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
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
