cross-tab lock coordination

the web locks api lets any two tabs of the same origin coordinate exclusive access to a named resource — with no server, no websocket, no shared worker. one tab holds the lock; all others queue. open this page in a second tab and try acquiring the same lock from both.

✦ open this page in a second tab for the full cross-tab demo

polled via navigator.locks.query() every 800 ms

• zero-server cross-tab communication. two tabs of the same origin can coordinate without any backend, websocket, or shared worker. the browser os handles mutual exclusion internally using the same mechanisms as service workers and indexeddb transactions.
• the queuing is real. if tab a holds the lock and tab b requests it, tab b's callback will not execute until tab a releases. this is hard mutual exclusion, not a suggestion.
• cross-tab state leakage. locks.query() shows which client ids hold or are waiting for any named lock — including locks created by other tabs for unrelated purposes. any page can observe lock contention across the whole origin.
• service workers use this. background sync, periodic background sync, and indexeddb transactions all use the same underlying locking mechanism. understanding web locks means understanding how your browser prevents data races at the storage layer.