Infinite looping on Cookie Store API with event listener

[RupinMittal]

Consider this code:

function runLoopingCase() {
cookieStore.onchange = (event) => {
printChangeEvent('Cookie got changed\n');
document.cookie="a=b";
};
document.cookie="a=b";
}

The spec says that any time a cookie is set, we should fire an event. This would mean that the above code will loop infinitely.

And indeed, on Chrome and Safari it does. A fix for this would be: "Do not fire the change event if the cookie being set is identical to an already-existing cookie". This makes logical sense and is how Mozilla fixed the issue: https://phabricator.services.mozilla.com/D217573.

Can we modify the spec to enforce that events are not fired when an identical cookie is set?

[RupinMittal]

CC @annevk

[annevk]

cc @DCtheTall @bakulf

[RupinMittal]

The above test case only sets cookies with document.cookie. This currently causes infinite looping in Chrome and Safari--but not Mozilla.

If we change the case to set cookies with the Cookie Store API, Mozilla also loops infinitely:

cookieStore.addEventListener('change', (b) => {
cookieStore.set("hello", "there");
console.log('change');
});
document.cookie='a=b';

Could any Mozilla folk explain why they fixed this only in the document.cookie change?

Also, I think the spec should enforce preventing this in both cases.

This would mean that if setting a cookie that already exists, we would not fire an event (unless I'm missing some edge case, this does make logical sense--it's a "change" event handler after all):

// event listener exists
await cookieStore.set("name", "value"); // event fires
await cookieStore.set("name", "value"); // event DOES NOT fire

What do we think?

[bakulf]

Could any Mozilla folk explain why they fixed this only in the document.cookie change?

It's simply a bug.

[johannhof]

Updating the spec to account for this case sounds like a very good idea.

[DCtheTall]

I have opened https://crbug.com/408035790 to track this issue in Chromium

[DCtheTall]

@RupinMittal this bug has been patched in Chromium, so Chrome versions 137+ should no longer have this issue.

Leaving this issue open while we continue working on incorporating this edge case into the standard.