Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
These functions were only used in some Java workarounds in NPAPI _getproperty.
MozReview-Commit-ID: FqCd5ss1VqQ
--HG--
extra : rebase_source : b1513e5dbdcf652b401529a5e3f9cfce09a73a62
extra : intermediate-source : 54c6b063aecba84c5a40bb1b1c298278b3d0b320
extra : source : 53754664b3c6eb49f3a9367e38776bf32739b85c
If there are still pending events after we null out gSocketThread, OnSocketThread() will always return false, which can trigger assertions.
MozReview-Commit-ID: CovFIU3cKL
--HG--
extra : rebase_source : e025dce2a347249be7a259fdcca2c6a8c6040d13
When writing to alt-data output stream fails for whatever reason, we now try to
truncate alternative data and keep the original data instead of dooming the
whole entry. The patch also changes how is the predicted size passed to the
cache. Instead of a dedicated method it's now an argument of openOutputStream
and openAlternativeOutputStream methods which fail in case the entry would
exceed the allowed limit.
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: HinC1UevOon
--HG--
extra : rebase_source : cf29f76826cc7728fd36505c8271bf50001c644c
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: HinC1UevOon
--HG--
extra : rebase_source : df2b80fcc03948e54f222e11060e1783f3b95421
* Also keeps the timing array as nsTArray<nsCOMPtr<nsIServerTiming>> instead of the scriptable nsIArray (which doesn't like being released on another thread)
MozReview-Commit-ID: 37uPZJ38saQ
--HG--
extra : rebase_source : 099ec74c3032ef6033d187a028466777200c6015
When normalizing the spec, some characters get percent encoded, so even if the original input was shorter than the max length, the final result could be longer.
MozReview-Commit-ID: 78IDM7Hoa55
--HG--
extra : rebase_source : b57caca6e5c55bf290b15e2f084e72e09f051c8f
This patch rewrites the rust-url-capi crate as the mozurl crate, which
provides a threadsafe MozURL object which is compatible with the
previous MozURL class.
Creating a MozURL this way performs a single allocation, which contains
only a rust-url Url object and an atomic refcnt, however it is fully
compatible with the C++ RefPtr type.
This patch also exposes methods for accessing dependent substrings of
the serialized spec, meaning that string copies can be avoided in many
situations when inspecting attributes of the MozURL.
--HG--
rename : netwerk/base/rust-url-capi/.gitignore => netwerk/base/mozurl/.gitignore
Adds a new TYPE_SPECULATIVE to nsIContentPolicy uses it as the type for
speculative connection channels from the IO service. I believe I've added it to
all the content policies in tree to make sure it behaves the same as TYPE_OTHER
used to.
The webextension test shows that the webextension proxy API sees speculative
lookups requested through the IO service.
MozReview-Commit-ID: DQ4Kq0xdUOD
--HG--
extra : rebase_source : d9460fdac118bc68f0db79749a16f181b580f2e7
The DNS service was shutdown and restarted again in several scenarios,
for example when one of its prefs changed and by nsIOService when going
offline/online. The DNSService restart dragged the resolver, TRRService
and others with it and they too were thus restarted.
Most notably this hurt TRR resolving, as the restart caused short gaps
in time when there was no TRRService available and nsHostResolver
defaults to TRR Mode "native" if there's no TRRservice up, causing the
name resolver to occasionally use the wrong or unexpected resolver even
though TRR is enabled.
The resolver restart also flushed the DNS cache which is now avoided.
It is also a performance gain.
MozReview-Commit-ID: pp4Y8bNQJk
--HG--
extra : rebase_source : 9e3b3e6c0df16b8ca6287d8045f594026ae9ad6d
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
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.
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
* Removes nsIStandardURL.{init,setDefaultPort} as these have been migrated to nsIStandardURLMutator
MozReview-Commit-ID: 7JPZmyEr65h
--HG--
extra : rebase_source : 5c40f1ff8eff0f73b54fb148923bab7b8b2270a7
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
This means we don't leave behind prefs-<n>.js files when prefs.js is read-only.
MozReview-Commit-ID: H6KKnoYGdhH
--HG--
extra : rebase_source : 263dd6fb75204a4565c8af89e7b21fc37a10d52e
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
* Makes the implementation of nsStandardURL::Mutator into a template called TemplatedMutator<T>
* Makes both nsStandardURL::Mutator and SubstitutingURL::Mutator extend TemplatedMutator<T>
MozReview-Commit-ID: EpxFpBkrdSK
--HG--
extra : rebase_source : 07d568ff84fb199c7549ae5f402e01e4b86c1c37
* The method can be chained just as the other methods on NS_MutateURI.
* In case the mutator object does not implement the interface, mStatus will be set to an error code.
* This is useful when you are constructing a new URI and the type of the mutator is known. I expect a future patch will add a MaybeApply method, that does not set mStatus to an error code if the mutator does not implement the interface.
* This patch changes nsHostObjectProtocolHandler::NewURI to use the new method and avoid a static_cast<nsHostObjectURI*>(uri)
MozReview-Commit-ID: 9kvXJX54gUP
--HG--
extra : rebase_source : 2a27778ec583251fac26c74d78125bd7266d6d87
Adds new network.http.referer.defaultPolicy.pbmode pref which defaults to 2.
When setting referrer from default policy, checks mLoadInfo OriginAttributes
for mPrivateBrowsingId > 0 to detect PBM.
MozReview-Commit-ID: 7SfNk0dO1rW
--HG--
extra : rebase_source : a050a61cad005740edde99f846a69c6a7568dbc6
* 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
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
The diversion mechanism never expected to be dealing with data sourced
from the content process, but that's exactly what happens with
ServiceWorker-intercepted channels with the current child-intercept
situation (which is being fixed).
In order to allow timely cancellation of diverted intercepted
channels, there needs to be a way to relay to the HttpChannelChild
that it needs to be canceled so that the synthesized pump can be
canceled and diversion can be marked as complete. This patch adds
such a mechanism to ADivertableParentChannel and PHttpChannel for the
exclusive use of InterceptedHttpChannel and then uses it.
--HG--
extra : rebase_source : db71e927bd1837c6a67f6d56df52cfbb7294df73
extra : source : d156f6b687e1cd8717bf813ab1b944e87b67ed5d
The diversion mechanism never expected to be dealing with data sourced
from the content process, but that's exactly what happens with
ServiceWorker-intercepted channels with the current child-intercept
situation (which is being fixed).
In order to allow timely cancellation of diverted intercepted
channels, there needs to be a way to relay to the HttpChannelChild
that it needs to be canceled so that the synthesized pump can be
canceled and diversion can be marked as complete. This patch adds
such a mechanism to ADivertableParentChannel and PHttpChannel for the
exclusive use of InterceptedHttpChannel and then uses it.
--HG--
extra : rebase_source : 59d3aa5e541d2a404c6320ae9fce03e7c9cd8b81
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 patch includes:
1. Save http trailers in the header array in chunk decoder.
2. Take trailers from chunk decoder in OnStopRequest().
3. Add serverTiming attribute in nsITimedChannel.
4. Parse server timing header when GetServerTiming() is called.
--HG--
extra : rebase_source : 77c92b8a31d3d7eebb33aea266888f944af33327
1. Create a new telemetry scalar SW_ALTERNATIVE_BODY_USED_COUNT to count the
number of the alternative body used in service worker synthesized channels.
2. To report values of fetching related time of InterceptChannel according to
the detail subresource type. Now subresource/script, subresource/other,
subresource/image and subresource/stylesheet are provided, and keep using
subresource for other types.
Initialize in advance all security services whose initialization on background thread could cause a deadlock.
--HG--
extra : rebase_source : 399f9acf736f9a06665d45a71b354076c1b85fa6
* adds MOZ_MUST_USE to C++ methods and [must_use] to idl interfaces
* Rearranges the code so it's more readable, and it fits within 80 chars
* Fixes indentation in BaseURIMutator
MozReview-Commit-ID: 3vG5eVaOC9U
--HG--
extra : rebase_source : df3b1120ba71a83adb41852e9003ef08af98b662
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
The ThreatHit requests were never being sent because SetMatchedInfo() was
called on the channel _after_ calling SendThreatHitReport().
Additionally, the telemetry was sent in OnStartRequest() and so errors
returned in OnStopRequest() would not be caught.
This patch also includes some improvements to the logging of these
requests which can be toggled using:
MOZ_LOG="UrlClassifierDbService:5,nsChannelClassifier:5"
MozReview-Commit-ID: 9dtRgEPVS3g
--HG--
extra : rebase_source : 6d0e4b745e203a54489ddd479935d008ab9a82d7
The logic for choosing the principal here was originally written before
loadInfo had a separate principalToInherit field, and we needed to specify it
via the triggeringPrincipal instead. At that point, we had to choose a
component principal with permission to load the URI at the start of the
request.
However, now that we have a separate field for the principal to inherit, it's
only needed after access checks have passed and we know that we have a URI
which inherits a principal. In that case, the current logic causes us to
always inherit the first principal in the whitelist (which is the page
principal) for URIs (such as data: URIs) that always inherit, where we really
want to inherit the last (which is the extension principal).
MozReview-Commit-ID: EPoUNuOCwrH
--HG--
extra : rebase_source : 535083e3dd4598ac4e8ea187d27d61ac2ac48476
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f