-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service worker example: stops working when SW is suspended #637
Comments
I don't think the SW gets cleaned up while the page is active. You could use the visibilitychange event to check every time the user comes back to the page. We've also implemented the Freeze/Resume Detection because our application gets suspended pretty frequently when it's not active. |
Ah yeah I've used page-lifecycle in the past, it handles pretty much all of those cases in a streamlined event system. That said, iPadOS seems to have issues where the document loses focus when you dismiss the keyboard. Anyway, will do some testing to make sure the SW doesn't get killed when the page is active, that would save me from a |
Yes, a ServiceWorker can definitely be killed even if the page is active. SWs are supposed to be lightweight and easily killable and respawnable. So unless you keep sending fetches or sending messages to keep it alive, it is likely that it will get cleaned up (esp. on mobile). I don’t think Comlink is currently set up to handle a killed-and-respawned SW gracefully. That would be a cool feature in the future. |
Yeah my testing so far confirms that (SW gets killed after 10~20 seconds, even with the page open). Not sure MessageChannel messages will keep it awake even. I have working code that will re-init comlink but it needs some cleaning up. Still, it's a workaround. The real solution is support for postMessage and Comlink needs to use |
@surma oh! Did not know that, do you have a good article/documentation at hand? |
Even It’s pretty well put at the start of the spec: |
Found a Chrome Developers blog post stating that MessageChannels do wake up ServiceWorkers. But the statement contradicts the code that's below it. I believe it's like you said, the service worker can throw away the port, Comlink, bathwater, baby, tub... 😝 What the example code in the article seems to suggest, however, is that Or how would you interpret that article's statement? |
Also found this old pull request from 2020 which suggests to address this problem: #493 |
@rejhgadellaa You should think of service workers like server-less functions when it comes to communication with the main thread. I am the author of a library called Transporter that was heavily influenced by Comlink but attempts to have more real work usability. Transporter supports communication with a Service Worker using the |
I've built a simple Notification API tester web app to do some debugging on what iOS Safari 16.4 does and does not support, and figured I could use Comlink to communicate between the main thread and the service worker.
I based my code on the service worker example, but found that, on Android at least, it stops working after a while when I put the page in the background and then come back to it.
I think I found the problem: the browser is free to suspend / completely kill the SW ifi it's not in use. That means it throws away everything: the port, Comlink, bathwater, baby, tub, etcetera.
I'm not sure if there is a (good) solution that doesn't require Comlink to support Client.postMessage(), because that's the one thing that will spin up the SW?
I'm currently trying some workarounds, like checking if the SW and Comlink is still alive, etc, but I fear that needs to happen with every call:
Will report back.
The text was updated successfully, but these errors were encountered: