- Shipped
- September 7, 2026 at 11:09 PM UTC
- Author
- Kamo
- Commit
- 44c843c
The client heartbeats its pane lock every 15s and the sweeper released any lock unheard from for 45s — three missed beats, which reads like a generous margin and is not one a browser can honour. Chrome clamps timers in a tab hidden for five minutes to ONE wake-up per minute. Measured, in the same run that found the notification deck's repeat dying: a 15s interval in a backgrounded tab really does become a 60s one, and 60 > 45. So a member who opened a lead, started editing and alt-tabbed for five minutes had the lock swept out from under them, their draft auto-saved and the lead handed to whoever asked next, while their pane sat open in front of them still believing it held the lock. An open WebSocket does not save it — measured too; sockets stay open and inbound frames keep arriving on time, but the page's own timers are still clamped. Nor is there a client-side interval that helps: no period a browser will honour is shorter than the minute it grants, so the deadline has to be set against what a browser actually guarantees. 150s survives two missed minute-wake-ups. It costs nothing in the ordinary case: a tab that closes or navigates away releases its locks explicitly, so this grace only ever covers a hard crash, and edit-idle-seconds (300s) still bounds an abandoned lock.