Nw.js: Nwjs 0.34.5 will not start after the registration of a service worker

[langco]

NWJS Version : 0.34.5 (In nwjs 0.30.4 it works)
Operating System : Windows 10

Expected behavior

After the registration of a service worker nwjs should start again after beeing closed.

Actual behavior

After the registration of a service worker. Closing and opening nwjs will produce a dialog and nwjs will not start anymore.

How to reproduce

1. Open attached example nwjs0_34_5_serviceworker.zip
2. Close nwjs
3. Start nwjs again

Nwjs will only start if I delete the service worker folder in the nwjs profile.

[langco]

I think it has something to do with this fix https://github.com/nwjs/nw.js/issues/6624.
0.30.4 was the last Version which didn't show this behaviour.

[Raakhuga]

Any updates?, having the same issue on v0.42.4

[zkrige]

seeing this issue on 0.42.4, but its working fine on 0.32.4

[Jaifroid]

Same problem in 0.44.1 - a Service Worker can be registered, and files can be fetched by Service Worker (but not cached because of the chrome-extension URL). However, on next opening the app, it crashes and tries to save the background_page instead of starting the app correctly. The only option is then to delete the profile folder in AppDatat/local (on Windows 10).

[zkrige]

I resolved this by changing some code in my service worker. I can't remember exactly what I did, but its an indication of bad code in the service worker itself

[Jaifroid]

@zkrige Thanks. It's a pity you didn't update this thread with your solution! Our Service Worker is a standard one with a CACHE-first strategy, designed for use in PWA contexts, where it works perfectly. At first it appeared that the problem arises because the Cache API doesn't work with the chrome-extension: URI schema, but we have rules in place to circumvent the cache if that URI is detected, and we are still getting problems using or even re-initializing the Service Worker on restarting the app. It seems like a low-level problem: fetch API fails, postMessage fails, quite drastic really. We see it in no other contexts than NWJS for the same app code, and ONLY after shutting down and restarting the app. Same problem as reported in this thread, so I can't believe it is "just" bad coding in the SW. Clearly we need to develop some workaround for an NWJS-specific problem.

[zkrige]

ahhh - now you're jogging my memory. I had an over aggressive fetch handler that was processing EVERYTHING. It was handling fetch requests that it didn't need to handle and trying to respond to those by processing the request and calling event.respond().

if you don't need to handle the fetch request, then DO NOTHING

here's what it looks like now

self.addEventListener('fetch', event => {
    if (event.request && event.request.url.startsWith('http://127.0.0.1:')) {
        const fetch = self.configureFetch(event)
        event.respondWith(fetch)
    } else {
        //do nothing - the browser will automatically handle unhandled fetch requests
    }
})

[Jaifroid]

Thanks @zkrige . I've experimented a lot with this, but I'm still running up against the fact that navigator.serviceworker.controller is null after restarting NWJS, even after re-registering the service worker, waiting for activation, etc. It's exactly the same behaviour described in the first post in this thread: the Service Worker registers fine first time, everything works perfectly, but if you exit the app and restart it, bam, the controller is null, re-registering it makes no difference, impossible to post messages between SW and app.js (or vice-versa), and so NWJS craps out and throws up a save window.

I'll try again with 30.4 or 32.4 as indicated above.

[Jaifroid]

32.4 doesn't work: the app fails to start, but it doesn't show the save window.
30.4 works in principle, but it is very unstable and crashes when scrolling in the app. But at least the app re-starts with the SW activated and able to load its content pages... But then crashes after a short period.