Updating components for document.cookie, possibly network>cookies folks?

I think this is a DevTools bug? Does the Console cache the result of JS execution? I wonder if the cookie is available longer than the allotted time outside of DevTools Console, or if this in the Console only?

dsv@, could you provide any insight?

FWIW I was not able to reproduce this on 123.0.6312.59 on MacOS 14.3.1

Hello,

I've just reproduced this locally by setting document.body.innerhtmlinstead of using the console.

It reproduces 100% of the time.

Essentially I'm expecting net::CookieStore to issue notifications for expirations but I assume that since this bug has be found this is not the case.

I'll start by determining if that's the case and if not if there is anything we can do to make that happen.

Found this thread while looking for documentation of this behavior in Chromium.

We had reports of an issue for our customers and tracked it down to some ancient frontend logic that uses a cookie with a 1 min expiry to limit fetch requests to a backend, and discovered that Chromium based browsers like Chrome, Edge, Arc (but not Brave) had the same issue with "document.cookie" still returning/holding the cookie set.

Triggering a fetch call that would send any valid cookies to a backend, or asking dev tools to reevaluate the cookie list seems to trigger a refresh and the cookie then disappears. The test linked above from march '24 has the same result as my local test harness.

These have the issue:

• Chrome 127.0.6533.120
• Edge 127.0.2651.98
• Arc: 1.5.0.31351 (Chromium Engine Version 125.0.6422.142)

These do not have the issue:

• Brave: 1.68.137 (Chromium Engine Version 127.0.6533.100)
• Firefox

Hello,

Thanks for the added details.

Since the optimization to avoid IPCs is really a best-effort thing I think it'd be fine to simply issue ourselves a delayed task to invalidate the cached version.

I'm validating that here to make sure it doesn't break anything and then I'll be able to add a quick test as well a a variable to either avoid overzealous posting/clearing.

That's actually a good point.

Looking at the code I'm trying to understand why there is no instance of CookieChangeInfo ever created with EXPIRED.

It seems like we would need this to avoid missing the expiry.

I'm impacted too. Another way to reproduce this:

document.cookie = "testme=Banana; Max-Age=4";
let i = 0
setInterval(() => {
  i++
  console.log(i, document.cookie)
}, 1000)

In Firefox, it will start logging empty strings from i=4 (as it should). Chrome/Chromium will keep logging the initial value :(

@morlovich: Thanks for the pointer that's a good point.

Would you be OK with us implementing the incomplete solution as I figure out the real fix so we can unblock the users reporting in the bug right here?

Talking to dylancutler@ about this another idea would be to leverage GetAllForUrl() instead of GetCookiesString potentially.

For reference, GetCookiesString already forwards to this function anyway, https://source.chromium.org/chromium/chromium/src/+/main:services/network/restricted_cookie_manager.cc;l=941;drc=5108636c70c0b08fdbeb57de2640a22e138f6685

We would just have to move the net::BuildCookieLine call to the renderer which seems benign to me. GetAllForUrl is already used in renderers by the CookieStore API.

We can scan the list of returned cookies for the minimum expiration date (ignoring session cookies since they do not expire over time when a page remains open). In future calls, if the min date is in the past, we invalidate the cache and make a new IPC.

Hello,

Just as an update I'm going to try to take this on this month and my plan is to implement the expiry task on the network service side with the minimal expiry (thanks Maks for the info on session cookies) on both setting, getting and change notification.

As I understand this will cover all cases:

• Expiry is set through JS as presented in this bug: Yes because delayed invalidation task posted on set.
• Expiry is set through HTTP response header: Yes because delayed invalidation task posted on change notification.
• Expiry was already set at time of first get: Yes because delayed invalidation task posted on first establishing the shared memory communication.

We are impacted by this as well, also pretty sure that it used to work fine before as we had functionality that depends on it that used to work, but has broke a few months back.

We have found one workaround (see the updated snipped below with document.cookie = ''; line) but not sure if there's any unexpected side effects from applying this hack.

The below code works as expected and the cookie dies after 4 seconds as it should.

    document.cookie = "testme=Banana; Max-Age=4";
    let i = 0;

    setInterval(() => {
      i++;
      document.cookie = ''; // Adding artificial call to manipulate cookie to force browser to remove expired cookies.
      console.log(i, document.cookie);
    }, 1000)

Hello,

As an update on this I've coded up a solution that works here: https://chromium-review.googlesource.com/c/chromium/src/+/5845710

I've manually validated that it works and I'm going to add a browser test to detect if this ever regresses.

Since that's going to be enough to fully validate the behavior for Chrome a full WPT is out of scope for me in the context of this bug.

I do share the surprise that one never existed in the first place though.

Project: chromium/src
Branch: main
Author: Olivier Li <olivierli@chromium.org>
Link:      https://chromium-review.googlesource.com/5845710

Have RestrictedCookieManager invalidate shared cookie version on get.

Have RestrictedCookieManager invalidate shared cookie version on get. 
 
This keeps cookies from remaining accessible in clients past their 
expiry. 
 
Bug: 331061798 
Change-Id: I01086cee71ed5dcf68d5d79e5dd1c6ae97c909f1 
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5845710 
Reviewed-by: Maks Orlovich <morlovich@chromium.org> 
Reviewed-by: Charlie Reis <creis@chromium.org> 
Commit-Queue: Olivier Li <olivierli@chromium.org> 
Cr-Commit-Position: refs/heads/main@{#1416966}