IMPORTANT:- This launch issue is used for standards and implementation tracking only.It is NOT for Chrome approval regarding privacy, security, legal, UI,testing,accessibility etc.- An overview of the different launch issues can be found here:http://bit.ly/2ncKZfp- If your feature requires security / privacy / etc approval then seek a PMto guide you through the go/newchromefeature processSee http://www.chromium.org/blink#launch-process for an overview of theBlink launch process, but note this doesn't cover security / privacy / etcreviews as discussed above.----------Change description:
This adds an asynchronous cookie API to documents and Service Workers.
Changes to API surface:
- write (or "set") cookies by self.cookieStore.set
- delete (or "expire") cookies by self.cookieStore.delete
- read (or "get") script-visible cookies by self.cookieStore.get
- ... including for specified in-scope request paths in service worker contexts
- monitor script-visible cookies for changes
- ... using new self.CookieObserver(callback).observe in long-running script -
- contexts (e.g. document)
- ... using addEventListener('cookiechange', handler) after registration during the InstallEvent in ephemeral service worker contexts by event.registerCookieChangeInterest
- ... again including for script-supplied in-scope request paths in service worker contexts
See the explainer on WICG GitHub for further in-depth discussion of the proposal: https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.mdLinks:
Public standards discussion: https://discourse.wicg.io/t/rfc-proposal-for-an-asynchronous-cookies-api/1652Support in other browsers: None, yet
Internet Explorer: Not yet
Firefox: Not yet
Safari: Not yet
IMPORTANT:
- This launch issue is used for standards and implementation tracking only.
It is NOT for Chrome approval regarding privacy, security, legal, UI,
testing,
accessibility etc.
- An overview of the different launch issues can be found here:
http://bit.ly/2ncKZfp
- If your feature requires security / privacy / etc approval then seek a PM
to guide you through the go/newchromefeature process
See http://www.chromium.org/blink#launch-process for an overview of the
Blink launch process, but note this doesn't cover security / privacy / etc
reviews as discussed above.
----------
Change description:
This adds an asynchronous cookie API to documents and Service Workers.
Changes to API surface:
- write (or "set") cookies by self.cookieStore.set
- delete (or "expire") cookies by self.cookieStore.delete
- read (or "get") script-visible cookies by self.cookieStore.get
- ... including for specified in-scope request paths in service worker contexts
- monitor script-visible cookies for changes
- ... using new self.CookieObserver(callback).observe in long-running script -
- contexts (e.g. document)
- ... using addEventListener('cookiechange', handler) after registration during the InstallEvent in ephemeral service worker contexts by event.registerCookieChangeInterest
- ... again including for script-supplied in-scope request paths in service worker contexts
See the explainer on WICG GitHub for further in-depth discussion of the proposal: https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md
Links:
Public standards discussion: https://discourse.wicg.io/t/rfc-proposal-for-an-asynchronous-cookies-api/1652
Intent to implement discussion on blink-dev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/gU-tSdjR4rA/hAYgmxiHCAAJ
Support in other browsers: None, yet
Internet Explorer: Not yet
Firefox: Not yet
Safari: Not yet
This sounds really cool.
Could I suggest Blink>Storage>Cookies? The Blink>ServiceWorker triage process works best when core service worker bugs are filed against it, and I imagine we'll have more bugs filed as implementation of the Async Cookies API progresses.
We (Facebook) have been reviewing our automated Chrome tracing data and we're seeing cookie as a huge source of jank. It's actually the single primary outlier. This would be very useful for improving page performance. We're seeing 1s+ outlier for document.cookie calls.
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.
We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.
For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit
For any questions, please contact owencm, sshruthi, larforge
The handling of the domain attribute is not quite spec-compliant: explicit values need to be (internally) prefixed with '.' to match the rest of Chrome.
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/fb17d1adfc6538ef3583a28544a025826b25839f
commit fb17d1adfc6538ef3583a28544a025826b25839f
Author: Victor Costan <pwnall@chromium.org>
Date: Fri Feb 23 03:42:26 2018
Cookie Store: Clarify that CookieStoreIOS assumes SystemCookiesAllowed.
CookieStoreIOS is one of the two iOS implementations of CookieStore.
Most methods that implement the CookieStore interface have
DCHECK(SystemCookiesAllowed()), whereas a few methods instead handle the
case where SystemCookiesAllowed() returns false.
It is unlikely that the resulting CookieStore implementation is usable
when SystemCookiesAllowed() is false.
* SetCanonicalCookieAsync() calls the system cookie store with no
workaround
* SetCookieWithOptionsAsync() DCHECKs
* GetCookiesWithOptionsAsync() DCHECKs
* GetCookieListWithOptionsAsync() calls into the CookieMonster
* GetAllCookiesAsync() calls into the CookieMonster
* DeleteCookieAsync() calls into the system cookie store with no
workaround
* DeleteCanonicalCookieAsync() calls into the system cookie store with
no workaround
Also, CookieStoreIOS() is currently only instantiated in
CronetEnvironment, which also sets the system cookie store's policy to
NSHTTPCookieAcceptPolicyAlways.
Bug: 729800
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I438b3c9c84f8fbc50a5494b0f9c6ef686b978eca
Reviewed-on: https://chromium-review.googlesource.com/931162
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Mohammad Refaat <mrefaat@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538689}
[modify] https://crrev.com/fb17d1adfc6538ef3583a28544a025826b25839f/ios/net/cookies/cookie_store_ios.mm
@pwnall: In comment#30 you added the CookieMonsterChangeDispatcher::Subscription class which keeps a |base::WeakPtr<CookieMonsterChangeDispatcher> change_dispatcher_|. You then dereference this WeakPtr in the destructor without first checking that it's non-nullptr:
CookieMonsterChangeDispatcher::Subscription::~Subscription() {
DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
change_dispatcher_->UnlinkSubscription(this);
}
I have some unit tests in my Content API-based application which are crashing during shutdown because |change_dispatcher_| is nullptr at this location. What is the expected behavior with regards to |change_dispatcher_| validity in the destructor?
Thanks.
@comment#48: I should mention that it began crashing for me between versions 68.0.3433.0 (#559327) and 68.0.3440.0 (#561733), so likely something else has changed w.r.t. CookieMonster or related lifespan to expose this crash.
Comment 1 Deleted