Seems maybe like we introduced a bug in regressing from expected behavior and this could arguably be handled as a bug-fix?
Regardless LGTM1 On Tue, Apr 30, 2024 at 11:32 AM Mike Taylor <miketa...@chromium.org> wrote: > On 4/30/24 7:15 AM, Ari Chivukula wrote: > > Contact emails > > aric...@chromium.org, johann...@google.com > > Specification > > https://html.spec.whatwg.org/multipage/system-state.html#cookies > > Summary > > navigator.cookieEnabled > <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> > currently indicates if “the user agent attempts to handle cookies” in a > given context. A change in Chrome, shipping as part of third-party cookie > deprecation (3PCD) <https://developers.google.com/privacy-sandbox/3pcd>, > would cause it to indicate whether unpartitioned cookie access is possible > (causing it to return false in most cross-site iframes). We should restore > the prior behavior of navigator.cookieEnabled > <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> > which indicated only if cookies were enabled/disabled for the site and rely > on the cross-vendor function document.hasStorageAccess > <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> > to indicate if unpartitioned cookie access is possible. > > I find it surprising that we changed the behavior of cookieEnabled in > https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ > - that wasn't clear to me when I LGTM'd. That said, HTML is shelling out to > RFC6265 - and the eventual promotion of 6265bis and subsequent Cookie > Layering work should make it all make sense in a 2024+ context one day soon > (one can dream, anyways). > > (Note I'm recused on voting from this one). > > > Blink component > > Internals>Network>Cookies > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies> > > > Motivation > > Divergence in the meaning > <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> > of navigator.cookieEnabled will cause confusion as Chrome rolls out 3PCD. > We have a window, before 3PCD ships, to restore prior behavior now that > there is some amount of consensus > <https://github.com/whatwg/html/issues/10256> between browser vendors on > what navigator.cookieEnabled should indicate in third-party contexts. > > TAG review > > This is a minor change to align browsers on standardized behavior so we > did not request TAG review. > > Compatibility > > Some websites adapting to Chrome’s 3PCD rollout > <https://developers.google.com/privacy-sandbox/3pcd> may have used > navigator.cookieEnabled as a proxy for document.hasStorageAccess, but we > will start recommending the use of hasStorageAccess moving forward. To be > clear, the behavior change is only web-observable in Chrome instances where > third-party cookie blocking is turned on. Metrics on third-party context > use <https://chromestatus.com/metrics/feature/timeline/popularity/4937> > of navigator.cookieEnabled are being gathered in M125, but without 3PCD > fully rolled out the impact should be minimal, especially where websites > wish to support Safari (which already adopts the behavior we propose > aligning with). > > > Interoperability > > Safari is already aligned but Firefox mirrors current Chrome behavior. > > Gecko: Preliminary positive feedback. > <https://github.com/whatwg/html/issues/10256#issuecomment-2049750772> We > asked if they’d like us to file a standards position for this relatively > minor change, and they said it’s not needed. > > WebKit: Shipping > <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> > > Web developers: No Signal > > Debuggability > > Access to cookies and unpartitioned cookies is visible in DevTools. > > Is this feature fully tested by web-platform-tests? > > Testing the effects of user-provided cookie settings on this function > cannot be done in WPTs. > > Tracking bug > > https://crbug.com/335553590 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/6227655153418240 > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLy9XBAFOyPdfRHE70nUStV0fAVWVSjL1xZDG7Mr4xnFQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLy9XBAFOyPdfRHE70nUStV0fAVWVSjL1xZDG7Mr4xnFQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34b3594a-4d10-4eaa-a341-7b173aff1eee%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34b3594a-4d10-4eaa-a341-7b173aff1eee%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-1Kf1aCfL3guApnotbHv%3D%2BKV%3Dryv9YHqY%3DTJ-2%3DW6LCQ%40mail.gmail.com.
