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
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