This new COOKIE_SCHEME_HTTPS telemetry probe reports the same information as the COOKIE_SCHEME_SECURITY probe, but also categories cookies by whether they are set from an HTTP or HTTPS origin.
MozReview-Commit-ID: IWg8dycCzwq
--HG--
extra : source : 94708be3f00796680377b3235b78f7db70c34510
extra : intermediate-source : eaf32e92b13d54a8e8d70a7b8caf420800641d49
"Nonsecure HTTP" here just means regular, not-HTTPS HTTP. It doesn't mean HTTPS without the `Secure` cookie flag. Honor the expiration time of third-party cookies set over HTTPS, whether or not they have the `Secure` cookie flag. If a third-party cookie is set over HTTPS and then later sent in nonsecure HTTP request (which is allowed for cookies without the `Secure` cookie flag), the cookie won't be turned into a session cookie unless the nonsecure HTTP response sets a new cookie value.
This feature is controlled by the pref "network.cookie.thirdparty.nonsecureSessionOnly".
MozReview-Commit-ID: HlCg21JyvNC
--HG--
rename : extensions/cookie/test/unit/test_cookies_thirdparty_session.js => extensions/cookie/test/unit/test_cookies_thirdparty_nonsecure_session.js
extra : source : d1be2e4265201efd3ee93e965ac68561f548fd05
extra : intermediate-source : f5b382fa1b70e30a907b1f10d74f8c0c6dff344e
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
I noticed a bug where the following can happen. The parent sends a
TrackCookiesLoad message followed by an HTTP OnStartRequest
message. When these messages are received in the child, the
TrackCookiesLoad message goes in the SystemGroup event queue and the
OnStartRequest message goes in the event queue for the relevant
tab. Unfortunately, this means that the OnStartRequest message could
run first since the queues have no guaranteed ordering.
We really should be putting the TrackCookiesLoad message in the same
queue that the OnStartRequest message goes in. I worked on that a
little bit, but it's hard to get right. For now, I would like to leave
the cookie message unlabeled. Any unlabeled message/event is totally
ordered with respect to all other messages/events, so this fixes the
bug.
MozReview-Commit-ID: KiLDAhlrbB8
These methods return an addrefed raw pointer, which makes them easy to use in
ways that cause leaks. If they're to continue returning an addrefed pointer,
they should explicitly return an already_AddRefed.
This also switches to StaticRefPtr with ClearOnShutdown for the cached
pointers for the sake of sanity.
MozReview-Commit-ID: D0lDpU8Hqug
--HG--
extra : rebase_source : 7b199070805fc0472eaf8409932517700ed23d49
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
All the instances are converted as follows.
- nsASingleFragmentString --> nsAString
- nsASingleFragmentCString --> nsACString
--HG--
extra : rebase_source : e6a1ddc8938fecd9a735b15e872c054edf4c7910
Evaluated every method exposed via nsICookieManager and
nsICookieManager2, and ensured that every method uses the right cookie
database depending on whether the mPrivateBrowsingId flag is set in
OriginAttributes.
The usePrivateMode method has been removed since it was introduced in
bugzil.la/777620 and not used anywhere else.
This should be covered by
toolkit/components/extensions/test/mochitest/test_ext_cookies.html,
but due to bugzil.la/1309637, the relevant private browsing tests
have been disabled. These tests will be enabled in one of the next
commits.
MozReview-Commit-ID: DMhE42LGu9S
--HG--
extra : rebase_source : 7882ed7610ff4c7c6f81a7852660d2b36a5c0a92
Avoids a thread-safety race condition on shutdown where we could try to finalize a statement twice.
Allows the async thread to be referenced until ShutdownAsyncThread, so async finalizers can make use of it.
Removes the no more useful mAsyncExecutionThreadIsAlive.
Nullifies the sqlite3_mutex pointer when the connection is closed, since it would be a dangling pointer.
Use a ScopeExit to ensure the connection and the mutex pointers are always nullified on failure.
Makes asyncClose bailout early if a Close method was already invoked before.
Makes AsyncInitDatabase not use AsyncClose to just shutdown the async thread.
Fixes various unfinalized statements in consumers code.
Makes mConnectionClosed better follow mDBConn status.
Replaces some mutex locking isClosed() calls with lockless isConnectionReadyOnThisThread.
MozReview-Commit-ID: 6sftFehsQTt
--HG--
extra : rebase_source : 2bf3088b500376e58e62e8f078d9950588adc649
Junior Hsu
Valentin Gosu
Sebastian Hengst
Masatoshi Kimura
Chris Peterson
Kris Maglione
Amy Chung
Bill McCloskey
Kershaw Chang
Josh Matthews
Kartikaya Gupta
Sylvestre Ledru
Will Wang
Nicholas Nethercote
Florian Quèze
Rob Wu
Marco Bonardo
Ryan VanderMeulen
Ehsan Akhgari
Christoph Kerschbaumer
Jonathan Kingston