Observed in versions: 2.6.x and 2.7.x (bindings-typescript)
What happens:
When a tab sits in the background for "a while" and the connection drops, the client sometimes stops retrying and does not reconnect when the tab returns to the foreground. It stays disconnected until the page is reloaded.
Steps to reproduce:
This is tricky to replicate and I haven't figured out the exact timing and dance to reliably replicate it, but I do have a fix for it (see linked PR). I had it happen more in Chrome & Arc. Mobile Safari seems to just reload the whole page if it sits long enough.
- Connect with the React client and confirm the subscription is live.
- Background the tab (or lock the machine) for several minutes to hours?? I would run into randomly while developing my app and returning to a tab I opened previously.
- Return to the tab.
Expected: the client reconnects shortly after the tab regains focus or the network returns.
Actual: the client stays disconnected with no further reconnect attempts.
Root cause:
Reconnect in connection_manager.ts is driven only by ws.onclose / onerror plus a setTimeout backoff. To my surprise, both are proving to be unreliable across a backgrounded or frozen tab. The close event can be dropped while the event loop is suspended, so #scheduleReconnect is never called, and background timers are throttled or paused, so a scheduled reconnect can stall and never resume
on focus. There is no visibilitychange / focus / online listener to re-check the connection when the page comes back.
Observed in versions: 2.6.x and 2.7.x (bindings-typescript)
What happens:
When a tab sits in the background for "a while" and the connection drops, the client sometimes stops retrying and does not reconnect when the tab returns to the foreground. It stays disconnected until the page is reloaded.
Steps to reproduce:
This is tricky to replicate and I haven't figured out the exact timing and dance to reliably replicate it, but I do have a fix for it (see linked PR). I had it happen more in Chrome & Arc. Mobile Safari seems to just reload the whole page if it sits long enough.
Expected: the client reconnects shortly after the tab regains focus or the network returns.
Actual: the client stays disconnected with no further reconnect attempts.
Root cause:
Reconnect in
connection_manager.tsis driven only byws.onclose/onerrorplus asetTimeoutbackoff. To my surprise, both are proving to be unreliable across a backgrounded or frozen tab. The close event can be dropped while the event loop is suspended, so#scheduleReconnectis never called, and background timers are throttled or paused, so a scheduled reconnect can stall and never resumeon focus. There is no
visibilitychange/focus/onlinelistener to re-check the connection when the page comes back.