The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
...down. The remedy to prevent the crash is to exit the loop when the
mShutdown flag is set. This does not attempt to address the underlying cause
of why the request continues to be pending, although this is also a concern.
Files changed:
netwerk/base/ProxyAutoConfig.cpp - expanded lambda containing logic of when
to stop waiting for the request to complete to include a check to the mShutdown
flag. Also logged a warning if the loop is exited because of mShutdown.
Differential Revision: https://phabricator.services.mozilla.com/D3977
--HG--
extra : moz-landing-system : lando
Disable TRR at will without needing to toggle the pref.
MozReview-Commit-ID: 1Ept6kDrjN3
Differential Revision: https://phabricator.services.mozilla.com/D3399
--HG--
extra : moz-landing-system : lando
The mIsTrackingResource flag on nsIHttpChannel was split into two separate
flags depending on whether or not the resource is third-party. The correct
flag will be set by the channel classifier. Similarly, a new function was
introduced, GetIsThirdPartyTrackingResource(), for those consumers (like TP)
who only care about third-party trackers.
The existing function, GetIsTracking(), will continue to look at both
first-party and third-party trackers (the behavior since first party
tracking was added to annotations in bug 1476324).
The OverrideTrackingResource() function now allows nsHTMLDocument to
override both mIsFirstPartyTrackingResource and
mIsThirdPartyTrackingResource, but since this function is a little dangerous
and only has a single user, I added an assert to make future callers think
twice about using it to opt out of tracking annotations.
Currently, only the default storage restrictions need to look at first-party
trackers so every other consumer has been moved to
mIsThirdPartyTrackingResource or GetIsThirdPartyTrackingResource().
This effectively reverts the third-party checks added in bug 1476715 and
replaces them with the more complicated check that was added in bug 1108017.
It follows the approach that Ehsan initially suggested in bug 1476715. It
also reverts the changes in the expected values of the tracking annotation
test since these were, in hindsight, a warning about this regression.
Depends on D3722
Differential Revision: https://phabricator.services.mozilla.com/D3723
--HG--
extra : moz-landing-system : lando
In this bug, we will focus on the problem of cannot download PDF file from google drawing successfully on MAC.
After investigating, I found that "SetTarget()" is called twice with two different addresses.
However, they both point to the same file.
We will assign the first target to "mInitialTarget" and the second one to "mRenamedTarget".
This problem happened when doing the second "SetTarget()".
After canceling the existing AsyncCopy, we will schedule a new AsyncCopy.
However, we only assign the mActualTarget with mRenamedTarget when they point to different files.
In this case, the two different addresses point to the same file.
So the mActualTarget is still the same as mInitialTarget.
After completion of the AsyncCopy, we try to do "CheckCompletion".
But it will always return false due to "mRenamedTarget exists" and "mActualTarget" is not the same as "mRenamedTarget".
The solution is quite easy.
We should always update mActualTarget with renameTarget, even if they point to the same file.
Differential Revision: https://phabricator.services.mozilla.com/D3400
--HG--
extra : moz-landing-system : lando
This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
nsContentTypeParser used internally a nsIMIMEHeaderParam reference, effectively limiting its use on the main thread, and as such restricting any methods handling mime type there too.
nsContentTypeParser only made use of a single method nsMIMEHeaderParamImpl::GetParameterHTTP, so we make that method static and export it via nsNetUtil.
Differential Revision: https://phabricator.services.mozilla.com/D2788
This makes it possible to use different lists for tracking protection
and for the features that rely on tracking annotations.
Differential Revision: https://phabricator.services.mozilla.com/D2484
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
nsIURIWithPrincipal is currently used to retrieve the nsIPrincipal from a
BlobURL object. BlobURLProtocolHandler has a hashtable containing, for each
blobURL, a BlobImpl and its nsIPrincipal. This patch introduces
BlobURLProtocolHandler::GetBlobURLPrincipal() that retrieves the nsIPrincipal
from this hashtable.
This patch fixes also a bug in how the revocation of blobURLs is broadcasted to
other processes. This should be done immediately because each process creates
its own timer to revoke them after 5 seconds.
An important change is related to NS_SecurityCompareURIs() where, if 1 (or
both) of the 2 URIs to compare, is a revoked BlobURL, we will QI its URL to
nsIStandardURL and fail out at that point.
The patch introduces NS_GetURIWithNewRef and NS_GetURIWithNewRef which perform the same function.
Differential Revision: https://phabricator.services.mozilla.com/D2239
--HG--
extra : moz-landing-system : lando
This delays the creation of the PAC thread until we need to dispatch a
runnable to it.
--HG--
extra : rebase_source : 8897d3d8724f082ad33027635795512ccb4a17eb
extra : source : 068bb4e7b8494d8ae82dfd1b1f22680234bf038c
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
This delays the creation of the PAC thread until we need to dispatch a
runnable to it.
--HG--
extra : rebase_source : dc4bffc041e237dddac7ae36a3a3b2f9c5de3421
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: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
This patch reduces the level of noise in MOZ_LOG messages by:
- splitting log messages into Warning, Info, and Debug levels
- truncating long URIs down to the first 128 bytes
- not mentioning suspended channels on NS_OK results
It also introduces new log messages for the outcome of a
match against the blacklist:
- dropping the channel priority (tracking annotations)
- cancelling the channel (tracking protection)
- no match (i.e. not a tracker)
MozReview-Commit-ID: wSQChJkMKv
--HG--
extra : rebase_source : 620c0b8f7094fa001d2389c99cbee6d547627fd9
This patch reduces the level of noise in MOZ_LOG messages by:
- splitting log messages into Warning, Info, and Debug levels
- truncating long URIs down to the first 128 bytes
- not mentioning suspended channels on NS_OK results
It also introduces new log messages for the outcome of a
match against the blacklist:
- dropping the channel priority (tracking annotations)
- cancelling the channel (tracking protection)
- no match (i.e. not a tracker)
MozReview-Commit-ID: wSQChJkMKv
--HG--
extra : rebase_source : ce8229414a3e3f4335af23253a6dc0c55fa9118a
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : eb7dc3e0921b12bbb3715a90863dc8e2a60c1c09
Changes:
- The API now returns a Promise containing a sequence of IOActivityData dictionnaries.
- All the code related to notifications and XPCOM is removed.
- The counters are no longer reset to 0 when the API is called
MozReview-Commit-ID: 7J2EgFqDgf
--HG--
extra : rebase_source : 4e16640a3f52fd7c042687471153971a66158623
This is to make sure that the test is using the same Captive Portal Service that nsIOService initializes.
--HG--
extra : rebase_source : 62bd371b8d510f596d3484aec6fad997739ada8b
Andrea Marchesini
Nicholas Nethercote
Jeff Walden
Henri Sivonen
arthur.iakab
David Keeler
Noemi Erli
Ehsan Akhgari
Diego Pino Garcia
Kris Maglione
Dorel Luca
Polly Shaw
Dylan Roeh
Cosmin Sabou
Tiberius Oros
Honza Bambas
Daniel Stenberg
Francois Marier
Alphan Chen
Valentin Gosu
Liang-Heng Chen
Brian Hackett
Daniel Varga
Adrian Wielgosik
Jan de Mooij
Jean-Yves Avenard
Masatoshi Kimura
Jeremy Lempereur
Jorg K
Nathan Froyd
Makoto Kato
Dipen Patel
Andreea Pavel
Byron Campen [:bwc]
Michael Kaply
Christoph Kerschbaumer
Eric Rahm
Coroiu Cristina
Margareta Eliza Balazs
Bogdan Tara
Tarek Ziadé
Robert Bartlensky