Avoid reporting races when open in multiple tabs

[derat]

The Updater class in updater.ts is susceptible to races if the web interface is open in multiple tabs. I think that the biggest problem is that it holds state in-memory while also persisting it to localStorage. When a second tab is opened, it'll load anything that the first tab has in localStorage (before rewriting the localStorage keys), and presumably both tabs will try to send it and also step on each other's toes in localStorage.

I wrote similar logging code in https://github.com/derat/ascenso/tree/main/src/log (and then updated it a bit further in a private repo). It uses tab-unique localStorage keys, and only reclaims other tabs' in-progress and queued records if they haven't been touched in a while. I think that it wouldn't be a drop-in replacement since the code in logger.ts has additional logic to resolve conflicts, e.g. when a rating or tags update for a song is received while an earlier update for the same song is queued or in-flight.

https://balpha.de/2012/03/javascript-concurrency-and-locking-the-html5-localstorage/ describes localStorage raciness and a possible workaround using Algorithm 1 from Lamport's 1985 A Fast Mutual Exclusion Algorithm paper. (I think that https://github.com/chieffancypants/fast-mutex may be another implementation of Lamport's algorithm.)

The comment from Ian Hickson on that page says that the spec describes a mutex that lets each script atomically perform multiple operations on localStorage, but Chrome (and other browsers?) apparently don't implement it. There's some discussion of the missing mutex at https://groups.google.com/a/chromium.org/g/chromium-dev/c/O7cTL4oC_VE, along with a suggestion that the Lamport algorithm doesn't work in this case. And yeah, see the warning at https://html.spec.whatwg.org/multipage/webstorage.html#introduction-15:

The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.

It looks like there's a Web Locks API now that has broad support, so maybe I could use that to synchronize localStorage access across multiple tabs.

A more robust way to fix this might be to run the reporting code in a SharedWorker. It apparently isn't implemented in mobile browsers (where I don't run the web interface, but still, yuck).

The easiest thing to do might be to listen for storage events and display a warning if the site is open in two tabs.

But what I'll probably do is to change the Updater class to use instance-specific localStorage keys and only reclaim other instances' data when it hasn't been touched in a while. I don't think I need to worry much about conflicting updates across different tabs -- if I'm listening to music in multiple tabs at the same time, I have bigger problems.