feature request: browser.cookies.onChanged - return previous cookie properties on overwrite/update

[crunk1]

Problem

I'm trying to determine what the previous value (or lack thereof) of a cookie was when setting the cookie. The browser.cookies.onChanged documentation says that two events occur when a cookie is overwritten: 1) a removal event, 2) a setting event.

However, the documentation/specification isn't explicit about notification delivery order. Is it possible for the removal event to be delivered to listeners after the setting event? Is it possible for other cookie change events to sneak in-between the removal and setting events? Or is it guaranteed that a cookie overwrite will deliver the two notifications in-order (removal, then setting) and back-to-back?

Proposal option 1:

When setting a cookie, add a previousCookie (or similar name) value to the browser.cookies.onChanged event. previousCookie would contain the previous cookie details, or null or undefined if the cookie was not previously set.

Proposal option 2:

Update the documentation/specification to give a more explicit, deterministic behavior.

A high-level, paraphrased example, "Updating a cookie value will first remove the existing cookie and then set the cookie with the new value. A removal notification with a cause of 'overwrite' will be sent, immediately followed by a notification of the setting of the new value."

Chromium ticket

I first filed this at https://issues.chromium.org/issues/447174547. Below, the documentation and namespacing are based on Chrome/Chromium.

Currently, overwriting/updating a cookie generates two events: 1) a cookie removal event with cause "overwrite", and 2) an event for the setting of the new properties. The chrome.cookies.onChanged documentation says event 1 will always occur before event 2, but it doesn't make any delivery guarantees about the ordering.

For reference, here is the documentation:

Fired when a cookie is set or removed. As a special case, note that updating a cookie's properties is implemented as a two step process: the cookie to be updated is first removed entirely, generating a notification with "cause" of "overwrite" . Afterwards, a new cookie is written with the updated values, generating a second notification with "cause" "explicit".

This current behavior kinda separates the two events, making it difficult to know if a particular setting event replaced a previous value or not.

Proposal:

Add a previousCookie field (or similar) for setting events.

My use case:

At my work, we're trying to synchronize a few cooperating extensions. I am attempting an approach using the cookie store as a psuedo-lock: the first extension to set cookie X gets to do the thing.

If this proposal sucks, could I instead ask a few questions?

As I said above, I don't think the documentation makes any explicit guarantees about onChanged event delivery order.

• Can I assume that updating a cookie will always deliver an "overwrite" removal event before the new setting event?
• Is there any chance that those events will always be back-to-back?
  • e.g. if I update a cookie with a new value foo, replacing the cookie with value bar, and I see the setting event for the cookie with the "foo" value, will the previous event be an "overwrite" removal event for the "bar" cookie?
• In the absence of delivery order guarantees, here is my current idea:
  1. Tag each service worker's try for the lock with an identifiable value - could be the extension ID, could be some other randomized value.
  2. Watch for setting events on that cookie for an arbitrary amount of time - a "settling" period.
  3. Extension that set the lowest value gets the lock.

Other suggestions about synchronizing multiple service-workers locally? I'd prefer to not set up some external arbiter service. And consensus algorithms with service workers seems like...a lot haha.