need to improve documentation on service worker changes

[acroyear]

I found that having a react-scripts 1.1.4 install then upgrading to 2.0.4/5, my service worker cache stuff would break. I could unregister in chrome by hand in devtools-application, load the app, it would register. Then if I were to control-r reload in Chrome, I would get nothing but 404's of the generated .js files. Only explicitly unregistering it would i get them back again.

It seems there are incompatibilities between the old registerServiceWorker.js file and the code that is used for the new version's serviceWorker.js.

Fix is to delete registerServiceWorker.js, copy serviceWorker.js from another more recently initialized project, and update the lines in your index.js file (the import and the actual register - look at the other project's index.js for the examples).

In addition, there are hyperlinks in "Making a Progressive Webapp" documentation that go to 404 pages, around the manifest.json mentions at the bottom. https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app

[TomPradat]

I don't know if it's related but i upgraded from 1.1.4 to 2.0.5 and now have troubles with cache when releasing a new version of my app. The service-worker seems to detect correctly that the files have changed but don't update the files correctly. I'll try to update the registerServiceWorker.js file and update this comment.

EDIT:

Yeap this is related. I used to use window.location.reload when new content was available but this doesn't work anymore.

[acroyear]

yup. it doesn't release the old versions from the cache when the old register is deployed with a 2.0.5 react-scripts framework. You have either hope it 'times out' eventually and refreshes properly, or unregister the service worker and let it start up again fresh on the next reload.

On mobile it simply always serves up the old pages. On desktop, I got the 404 problem.

Easy enough to clean in devtools for Chrome Desktop (go to the Applications tab). Requires chrome://serviceworker-internals/ (and a lot of scrolling to find the app) in mobile.

[Timer]

/cc @jeffposnick can we highlight the new skip waiting behavior more somehow?

[acroyear]

hmm...actually, even after my fix to use the current service worker code in all places, i'm still having issues with caching. my app is getting a blank screen when it starts up, hinting that something significant in the javascript didn't load. if i unregister, it works on the first startup, but the next drag-down to reload and it goes black again.

I made no changes to the contents of serviceWorker.js.

https://subfiresuite.com/dash/

on desktop it seems fine, so far. (note, page won't likely load any data because the default site is http only, causing a mixed content error)

[jeffposnick]

#5410 was merged to update the PWA docs to clarify the current behavior. I made that PR against the old react-scripts/template/README.md file, though—if there's a new source of truth for the docs, then perhaps I need to commit the same change to a different file?

[iansu]

@jeffposnick It looks like your changes from that PR are present on this page in the docs: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app. I think @Timer may have meant emphasizing those points more in some way.

[jeffposnick]

Gotcha. Well, #5491 would help in terms of developer visibility outside of the docs, in that it adds in an additional log message and hook into the config.onUpdate callback.

We could update the docs to give an example of what config.onUpdate might look like, but... I'm not much of a React programmer, and I'm not really sure of what the canonical way of showing a Toast message would be. Maybe @arackaf wants to share in the PWA section of the docs the type of callback he's implemented?

One step further would be to commit some code in c-r-a that provided an config.onUpdate Toast callback by default, which would make things much more visible. There has been pushback against committing this sort of code in the past, though: #2426

[NTag]

On my application, after upgrading to 2.0, I got two service workers, with he same name service-worker.js: the old one from sw-precache-webpack-plugin and the new one from workbox. And the issue is that index.html keeps being served by the old service worker (so the JS scripts links it contains don't exist anymore, and the page stays blank, which is quit annoying for users, I can't ask them to go into developer console to clear the cache or whatever).

I think something is missing to unregister the old service worker, or to clear its cache, so it can't serve anymore a wrong index.html.

[acroyear]

NTag's description is precisely what I've been seeing happening.

[NTag]

I reproduced the issue: clone this repo https://github.com/NTag/create-react-app-sw-issue-5528 and follow the steps in the Readme. Using Chrome, the old content keeps being served (I didn't manage to reproduce the "blank page" issue, but still, it reproduces a similar bug).

[arackaf]

You need to close the tab and re-open it. The newer sw is probably in waiting mode

[acroyear]

I've killed the tab. I've killed my browser. I've, in the case of the Android PWA, totally uninstalled it and reinstalled it. I see these same results. The old SW is still there, still trying to serve up cached content that doesn't exist anymore.

[arackaf]

Have you confirmed the newer sw exists? Can you see it being requested in the network tab?

[acroyear]

ok, yes in one case, the old service worker was still there. The new one in "waiting" mode. i had to force it in Applications tab.

Thing is, I shouldn't have to. I certainly shouldn't have to expect that my customers will have to do that.

In any case, that seemed to solve the problem for Desktop Chrome, my PWAs on Android (9, Chrome-Dev M72) are still totally hosed. I unregister the SW (through the chrome://serviceworker-internals url), load my app. It works. I then slow-drag down on the screen to restart it and I only get a totally blank screen. I can repeat this on demand. I totally wiped the folder before deploying to be sure no archival content was there.

https://subfiresuite.com/base/#/

[acroyear]

workaround - in the generated service-worker.js file, comment out all caching.
// self.__precacheManifest = [].concat(self.__precacheManifest || []);
// workbox.precaching.suppressWarnings();
// workbox.precaching.precacheAndRoute(self.__precacheManifest, {});

since my app is an online music player, it doesn't matter to me for actual "offline" usage. I just needed the service worker because I wanted homepage pwa deployment.

[tyler-dunkel]

Has there been any update on this? I am using CRA and am having a similar issue. I build the production app with npm run build and then serve it with the serve package serve -s -c 0 build I notice that the service worker is running and the assets are being cached correctly. Now I go back to the app, change something, rebuild, and re-serve the app. On the next SW update call, the onupdatefound event is fired which results in the page reloading. However, I am still seeing the old cached assets. Looking in the chrome devtools, I see that the old SW is still in active and running mode while the new SW is in waiting mode. Is there a way that I can pass skipWaiting to this service worker without updating the CRA service-worker.js file? I am unable to get my application to load the new assets without manually clicking the skipWaiting button in devtools or by closing out the tab and reopenning it. Please advise.
Thanks!

[Graham42]

Discovered the root cause of the blank screen issue for myself. This may be true for others as well.

A key file (main.js) was not being cached by the old service worker due to its' size. (See #2612 for details). This meant that when a new build was available, and the service worker did not skipWaiting as is the default for 2.x, that the old app could not be loaded, and the new app would not activate yet.

NOTE: If this is the cause, then your offline behaviour was broken before and it just went unnoticed because of the different skipWaiting behaviour.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.