30

Context

A game shipped as a progressive web app which has timers (setTimeout, setInterval) and websocket connections to get real-time communication.

What is happening

Everything is fine as long as the user stays in the app. But when the user goes to another tab, or another app or turns off the screen (in case of mobile), it becomes a "hellish unknown world".

  • Websockets may or may not become "paused" or "turned off"
  • Timers look like they are being throttled or debounced.

This behaviour seems to depend on browsers and platform and, maybe, even depend on the particular user behaviour. I guess browsers and OS have their own lifecycle / mechanisms to save battery and/or computation.

When the user comes back, the app is in an unknown state and I am struggling to restore the state properly.

Regarding websockets I have auto-reconnection with socket.io and reconnecting-websocket but it's not enough to solve everything.

Looking for answers

  • What are the "lifecycles" of the different browsers regarding these? Is this documented? When do they decide to turn off and throttle?
  • What do they do exactly to websockets? Browsers just disconnect them?
  • What do they do exactly to timers? They throttle them or debounce them or something else?
  • What happens to javascript execution in general? Paused / destroyed / throttled?
  • Is there a way to hook into some kind of browser lifecycle event when it's going to turn things off? The only thing I could find might be the visibility API

  • Is there a way to artificially reproduce this behaviour to be able to test solutions? It's especially hard on desktop. Websockets can't be turned off and chromium developers don't seem in a hurry to help an issue from 2014(!): websockets not included when using connection throttling

  • Regardless of the above, is there a pragmatic cross-browser solution to detect / solve this problem? (for example from experience, Firefox on desktop seems to behave completely different compared to Chrome, and an iPhone will disconnect far more often than an Android)

Related Links

Improve this question
5
  • 1
    This is just a draft wicg.github.io/page-lifecycle. Commented Mar 27, 2020 at 4:38
  • Related: developer.chrome.com/blog/timer-throttling-in-chrome-88 Commented Jul 1, 2021 at 22:11
  • Did you finally solve this? I am fighting with a PWA, or web app as well, that has its websocket silently killed by android running chrome after several minutes of inactivity. Commented Mar 18 at 21:56
  • @Graph It was a relatively long time ago. I can tell you that I had implemented multiple watch services that would constantly check the state of the app and the websockets connections. If anything was in an unexpected state I had mechanisms in place to restore the app state properly but it was not easy. Small note aside, nowadays I'm playing an online mobile game that, once the websocket connection is lost, will simply ask to restart the app. Might be much easier than trying to reconcile the state in your case. Commented Mar 19 at 22:16
  • @Kev you use Service Workers? You have samples or any code to share here? Commented Nov 5 at 17:48

2 Answers 2

Reset to default
9

Not exactly sure, but you could use service workers. As much as I know, they run in background even if your tab is not opened and get terminated if your tab closes.

Btw. lifecycles of browser tabs seem to be different on every browser, since every browser handles it different. From what I see the browser can freeze tabs if it needs more memory for other things.

Here is the docs from Chrome.

I remembered that there are some events, like onload that tell you if a user has left or reopened the tab. You could use these event to reconnect etc..

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

This is an interesting idea. Is this something you have done with some code to share?
Im sorry, I don't have an example code right now, but if you search for service workers, there are a ton of tutorials how to set them up. The only thing you have to do is put just a small code where you connect to your ws-server and a console.log() when you get messages from the ws-server. In chrome you can open the console of your service worker and so you can test if the messages are revieved when you leave the tab.
Great idea, it worked just fine for my case, now I have 1 less problem :D
1

I would give different advice regarding how to design your app. From what I understand your intention is to add more logic in order to understand if the user is no longer active in the browser. This entails a different problem which is browser specifics to implement that logic. With that in mind, I would instead invest in have better error handling, both in the server and client.

Errors won't be browser-specific. Handling those will make your app more resilient and agnostic to browser changes, that could eventually change, let's say, the way they hibernate a tab, any other feature that a vendor might implement in the future.

This is an idea that you can find in services architecture, but the same pattern applies to any web-app. You might want to look for Design-for-Fail concepts:

Complexity makes it infeasible to assume robustness on the part of the systems upon which one relies. Instead, one needs to design systems and applications at any given layer in the IT stack-based to assume the possibility of failure at lower levels. Design-for-fail necessitates thinking about fault tolerance at all layers. No longer can application developers confine themselves to thinking about functionality.

https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html

Improve this answer

1 Comment

What kind of "better error handling" are you thinking about?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.