Service worker stuck on "trying to install" - install() runtime methods not being called.

[oller]

Hey guys, first off thanks for your work on making this plugin webpack 5 compatible!

I was wondering if you had any insight into an issue i'm having.... This same code used to work with webpack4 and the original plugin, now having moved to webpack5 and your fork, none of these console.log() are executed at all.

I've installed your fork, and updated the references to your plugin both at the webpack config and from the app.js to reference this runtime.

 try {
        OfflinePluginRuntime.install({
            onUpdateReady: () => {
                console.log("offlinePlugin: onUpdateReady");
                try {
                    console.log("offlinePlugin: applyUpdate");
                    OfflinePluginRuntime.applyUpdate();
                } catch (error) {
                    setTimeout(() => {
                        OfflinePluginRuntime.applyUpdate();
                        console.log("offlinePlugin: applyUpdate via 1 min setTimeout");
                    }, 1000 * 60 * 1); // try again in one minute
                }
            },
            onUpdated: () => {
                console.log("offlinePlugin: onUpdated");
                setAppUpdateAvailable(true);
            },
        });
    } catch (e) {
        // service workers not supported
    }

I know ServiceWorkers can be a little sticky, so just wanted to get your thoughts if i'm doing something silly, or if there are any other steps i'm not aware of when upgrading.

In devTools I can see the sw.js seems to get stuck on 'Trying to install'. Again this is with Brave and Chrome was never previously an issue. I believe this to be at the heart of the problem, the service worker isn't registering.

For additional context - the 2 generated sw.js files:

webpack 4 + original offline plugin: https://pastebin.com/zwSrCHFC
webpack 5 + this fork : https://pastebin.com/hT1Zsn4b

The config options at the top seems the same shape (albeit with a few changes as a result of the migration) however the function part at the bottom seem very different.

Any input much appreciated.

Many Thanks!

[LeComptoirDesPharmacies]

Hi @oller,

The fact that sw.js step "trying to install" stuck is very strange.

You are right about function part being different.
I wonder if it could come from weppack generating the sw.js using ES6 (arrowed functions, etc...).
Indeed, in your Webpack 4 sw.js version, function part starts with :

! function(e) {
    var n = {};

But in your Webpack 5 version it starts with :

(() => {
    var e = {
            634: (e, n, t) => {

Could you try to put 'ES5' in your wepback configuration to see if it makes any differences ?
Ex :
`target: ['web', 'es5'],

Without a browserslist webpack's runtime code uses ES2015 syntax (e.g., arrow function) to build smaller bundles. Hence you'll need to set target: ['web', 'es5'] to use the ES5 syntax for browsers (like IE11) which don't support ES2015 syntax .
(Ref : https://webpack.js.org/migrate/5/#need-to-support-an-older-browser-like-ie-11)

Yours faithfully,
LCDP

[oller]

Hey @LeComptoirDesPharmacies

Thanks for the response, I have been working on this for a few days, it just gets weirder! I'll try what you've mentioned, but for more context, the webpack 5 service worker works in firefox, it's a chromium specific issue. and if I comment out some files, it'll register correctly.

I even tried swapping around the function block of sw.js, so the webpack4 compiled one with the webpack5 config object, and that worked fine (once files were commented out). So I don't think the issue is with the js minification or es6 etc.

However there doesn't seem to be any logic to the files I comment out, I can have some files that work (in the array at the top of the sw.js), then another few files in the array that worked standalone too, however when I try them both, it'll get stuck in this state. This is just playing with small svg files i'm commenting in and out. So it seems it's not about the content of the files, but the number of filesize..?

I wouldn't say the app is exccessive in size - this is a dump of the analysis of stats.json (before gzip)

🤔

[LeComptoirDesPharmacies]

The fact that it works on Firefox but Chromium is very strange.
May it come from different SW "SDK" implementation on both sides ?

Indeed, your application is not that big and I do not think it could come from heavy content as our app take more than 20 MB without any trouble.

If this can help you, here is a pastebin of the sw.js on our website which is running on Webpack 5 + Offline Plugin 5.1.0 :
https://pastebin.com/uxjNHAyL

[oller]

OK great, much appreciated - i'll keep investigating. Thank you again for your responses and the time taken to fork this repo.

[oller]

OK, so having worked my way through the assets in the sw.js commenting those in and out and re-testing. I've got it down to 4 specific files, if any of which are included, the service worker will fail to install.

"/robots.txt"
"/" // which is "index.html" before plugin performs 'rewrites' 
"/public.html" // a secondary entry point we have
"/favicon.svg"

Seeing as these are small files and not really the core of the application, for now i've excluded these

            excludes: ['**/robots.txt', '**/favicon.svg', '**/index.html', '**/public.html'],

I've no idea what is special/different about these files that they become an issue (apart from they're all on the root where most are within an assets/ dir). They're some of the smallest files out of the lot, so size isn't an issue. In any case, i'm unblocked, but it's not an ideal solution.

Just adding this update in case it's of use to anyone!

Relevant to today:

[LeComptoirDesPharmacies]

Nice that you successfully identify which files are causing you some troubles !
It is a bit strange but there should be a logical reason that we did not found yet.

Do you confirm that these files are present in your final dist folder ?
May it come from wrong hash like if a plugin modify their content after OfflinePlugin hash computation ?

What you could try :

• Modify the hash in sw.js from a working file and see if it produce the same error as for these four files.
• Try to put these files in "optional" or "additional" lists and see if it changes something.

Yours faithfully,
LCDP

[jampy]

maybe related: NekR#486

[jampy]

Yeah, I'm pretty sure the issue is related to NekR#486: offline-plugin starts all fetch() requests in parallel and does not consume the responses one by one but instead waits for all fetch() requests to complete. Chrome appears to support only a limited number of pending fetch() requests.

The exluded files mentioned in the comment above likely only reduce the number of URLs needed to be fetched and has nothing to do with the files themselves.

The solution is to cache.put() the responses immediately, not when for all fetch() requests completed.

I started to create a patch (patch for src/misc/sw-template.js, that actually solves the problem discussed here) and wanted to create a PR but the offline-plugin code seems rather obscure to me and I found some likely bugs along the way (mutation of the requests parameter and use of cache.match() without checking for undefined which in my tests caused errors). So currently I try the switch to Workbox even if offline-plugin-patched 4.9.1 worked well for many years in combination with Webpack 1 (yes!).