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.
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.
InitializeOriginAttributes takes aArgc and only initializes the
parameter when aArgc is 1. nsCookieService::Add takes another optional
parameter, namely aSameSite. If a caller sets this SameSite flag, then
InitializeOriginAttributes would skip the initialization of the
OriginAttributes.
This was caught by a private browsing test in
toolkit/components/extensions/test/mochitest/test_ext_cookies.html
(after I added support for SameSite flag in the extension API)
MozReview-Commit-ID: HLfte7x1X7T
--HG--
extra : rebase_source : 1feb84ceca157d8c5ec8575c6336cc606c3504fe
After writing a unit test I discovered that updating a cookie's samesite
flag did not work. This is caused by an "optimization" that avoids
modifying a cookie if any of the cookie attributes were not changed.
This check did not account for the SameSite flag, until now.
A unit test for this will be added in a later commit, at
toolkit/components/extensions/test/xpcshell/test_ext_cookies_samesite.js
MozReview-Commit-ID: ChiwwqqOE57
--HG--
extra : rebase_source : f6bd9bd650f6db50a0726451cd781ca7984962a1
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This patch reverts parts of changeset e87e706def11 (bug 1425031).
The problem in bug 1425031 was that when the content process set a cookie
a notification was sent to the parent process. This notification was then
forwarded to all the content processes, including the one it originated from.
The solution was to not forward cookies that originated from a content
process, but this causes the current bug.
The correct fix is to forward the cookie changes to all content processes
except the one they originated from.
The test for bug 1425031 remains, and should keep passing.
MozReview-Commit-ID: 1P6JwHQDy93
--HG--
extra : rebase_source : 85845c93059004836e14d5a46f2df881237fad6e
There seems to be no reason to conditionally fire the cookie-db-read event. Currently it is not fired if no cookies were read. There seems to be only one other consumer of this event (a test) which should work fine if the event were fired every time. This change would eliminate a particularly ugly workaround in cookie-related policy testing.
MozReview-Commit-ID: FbD1cvsBZBO
--HG--
extra : rebase_source : 6611debb3567310c61e5a5dc9cedadeae888cfe5
There seems to be no reason to conditionally fire the cookie-db-read event. Currently it is not fired if no cookies were read. There seems to be only one other consumer of this event (a test) which should work fine if the event were fired every time. This change would eliminate a particularly ugly workaround in cookie-related policy testing.
MozReview-Commit-ID: FbD1cvsBZBO
--HG--
extra : rebase_source : ff5049f36c7f3df3ad182ebb1a6ccc5db1032e23
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 {, <