Collect use cases for web locks

[ralph961]

This has been a very valuable API for us. We use a hacky, “not the real thing but usually doesn’t cause bugs” pseudo-polyfill for FF and Safari. It would be really great to hear news on whether this will get traction outside Chrome/Edge.

Also v anecdotal but if it’s interesting to hear dev feedback from people using this API in production:

• at some point, we have actually needed every feature exposed here
• yet at no point has it ever seemed anything was missing
• and it is an absolute pleasure to use

Originally posted by @bathos in https://github.com/WICG/web-locks/issues/55#issuecomment-897116233

[ralph961]

@bathos curious to know more about your use case.

[bathos]

1. Ensuring there’s only a single websocket connection across any number of clients. This optimizes for the common case that there’s only one client (vs SharedWorker, say — but that’s not supported in Safari anyway) while allowing folks who open many clients to “share” a single connection (the current lock-holder broadcasts to them — and if the client closes, the lock is released and next client obtains it and becomes the socket-haver, etc).

2. Ensuring only one client surfaces a single user agent credentials prompt for PasswordCredential with mediation: 'optional' at a time. The mediated flow can’t be aborted from the JS side, so they’ll just stay open even after the user may have signed in (via another client). In this case we would use ifAvailable: true — we don’t want to do anything if another client already has this flow open.

3. For those using PublicKeyCredential for passwordless auth instead, the mediation is abortable (via AbortSignal) and always begins with an explicit user activation, so the situation is a bit different. Here you need steal so that if there’s a prompt for platform credentials open in one client when they click “sign in with Windows Hello” (etc) in another client, the other one’s lock is lost. The same signal can be used with the credentials API that tells it to cancel 😍 — so whatever leads to it (e.g. credential UI timeout) will end the other.

4. After init, we verify whether the current authenticated user’s push subscription status and what’s reported in the agent are in agreement and “realign” them if not. For example, a user might choose to disable all push notifications from another browser or device, in which case we would delete the records of those subscriptions on the server but they would still be lingering in this browser; we’d want to now delete that lingering subscription. But if a user e.g. opens a browser where they had multiple clients open and the all load at once, this clean up would be attempted simultaneously for no reason. With a lock, early “verify / update origin-level stored state” work doesn’t get duplicated and doesn’t race (just like in IndexedDB’s upgrade model — which is, after all, the same problem, but there’s nothing specific to IDB about “origin level storage of stuff exists”).

[ralphch0]

Thanks for the info!

[bathos]

Sure, happy to share feedback for one, two, or more ralphs. :)