Cookie Store API can read cookies set by document.cookie but not delete or modify them (if the cookie has a path)

[RupinMittal]

The WPT tests for the Cookie Store API check that the API is able to read cookies set by document.cookie (and vice versa). This seems to imply that we want the API and document.cookie to be in sync and provide the same results--as in, you can use either to accomplish the same result.

But currently, based on the instructions in the spec, the API cannot delete or modify cookies that were set by document.cookie if those cookies have a path. (This is the behavior on both Safari and Chrome). The issue is this:

When document.cookie sets a cookie, it does not append a "/" to the end of the path. But the Cookie Store API spec says that it must append a "/" to the end of the path if one is not already there (step 12 of https://wicg.github.io/cookie-store/#set-a-cookie). If two cookies have the same exact properties (name, value, etc...), but the path's differ by an ending "/", they are considered two different cookies.

For example, on a URL with a path, like https://www.foo.com/bar, we see:

document.cookie="cookieName=cookieValue"; will set a cookie with path "/bar"
await cookieStore.delete({ name:'cookieName', path:'/bar' }); will attempt to delete a cookie with path "/bar/"
There is no such cookie and so:
await cookieStore.getAll(); will show the cookie set by document.cookie

Do we think the spec should be modified to not append an ending "/" so that document.cookie and this API can be fully in sync?

[annevk]

The appending of / was done in #192 but the rationale is unclear and it actually seems like rather weird behavior. @ayuishii and @inexorabletash could you provide context?

[annevk]

@johannhof could you maybe get this prioritized? Thanks!

[johannhof]

@DCtheTall was going take a look, I think

[DCtheTall]

@johannhof @annevk I was able to reproduce this on Chromium fairly easily following the instructions from @RupinMittal

I have assigned myself https://crbug.com/402779102 to track patching this in Chromium