Sometimes the ServiceWorker ends up in a state where it does not handle anything more, even if it's registered and enabled

[mossroy]

This stucks the application.
I saw that both on Chromium and Firefox dev edition.

Workaround : remove manually the ServiceWorker and reload

[mossroy]

After some debugging, it seems to come from the fact that the service worker has been stopped by the browser (after some inactivity).
When it is needed again, the browser starts it again. But its variables values have been lost in between, especially the messageChannel that allows to communicate with the application.
Some data can be kept in IndexedDB, but I can't keep the messageChannel in it.
So I need to find a way to re-initialize the ServiceWorker when it is re-started by the browser.

[mossroy]

Re-sending the 'init' message to the ServiceWorker makes everything work again. Because it sets the MessageChannel. It can be done from the UI by selecting the jQuery mode, then switching again to the ServiceWorker mode.
Unfortunately, there doesn't seem to be a way to add an eventListener (or something similar) on the application side to be informed that the ServiceWorker has been restarted.
And the MessageChannel can not be created by the ServiceWorker itself when it is started : it must be created by the application, and passed to the ServiceWorker, so that it becomes a way to communicate from the ServiceWorker to the app.

So I don't see any other way than sending periodically the 'init' message (or creating a dedicated type of message), to maintain the state of the ServiceWorker.
The spec does not seem to give any recommendations about when a ServiceWorker should be stopped/started. I suppose each browsers can implement its own strategy (to save memory, CPU, battery life etc). On Firefox & Chromium, it seems to be stopped after being idle for many minutes (or even hours?), and then restarted when needed.
An initial approach would be to send the 'init' message each time the user does a search. But it does not solve all the use-cases : if the user already has a page displayed, leaves it for a few hours, and then clicks on a link in it, it will still fail. If we wanted to send this message each time the users clicks on a link, it would force us to parse the content for these links with jQuery, which is what we want to avoid with the ServiceWorker mode.
All in all, sending the 'init' message regularly (like every x minutes) should be easier, and should be working better. But, of course, it will prevent the browser from stopping the ServiceWorker and saving memory/CPU/battery. And the frequency should be chosen to be below the delay before a ServiceWorker is stopped by the browser (which we don't know precisely, and might vary between browsers/devices/versions/battery charge etc).

[Jaifroid]

I just wanted to report that as of the Windows 10 April 2018 update, Edge now ships with Service Worker switched on, no special flags needed. As with Chromium, it only works with the http:// protocol, not with file:// protocol, so it needs a local server, which is a shame. I've been testing it, and it works very well for the most part, and is snappy.

Issues experienced seem to be those described in this issue, broadly. If I "refresh" the browser page, to reload code, then the Service Worker stops working, until I've manually disabled it and re-enabled it again. I experienced exactly the same issue on Chromium, so it is not browser-specific. If I exit the browser completely, relaunch it and go back to http://localhost, even though both channels are shown as green, the Service Worker doesn't load CSS etc. until I manually disable it and re-enable it (I also experienced this with Chromium). I have not yet used it long enough to notice it disabling itself mid-session, as reported above.

[mossroy]

I found a last use-case where this can happen : the user is in SW mode, then switches to jQuery mode, then switches back to SW mode.
I think I found a fix for that