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
Dylan Roeh
Cosmin Sabou
Ehsan Akhgari
Tiberius Oros
Honza Bambas
Henri Sivonen
Daniel Stenberg
Francois Marier
Alphan Chen
Valentin Gosu
Liang-Heng Chen
Brian Hackett
Daniel Varga
Andrea Marchesini
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