If a user visit the website on the first time, the browser would download index.html first, and then register the service worker.
But what if we roll out a new version right after the user gets the index.html, but before fetching the server-worker.js? The user would get a server-worker.js whose version doesn't match the index.html.
The only solution I can think of is that stop claiming clients automatically if we find the versions mismatch. Is there any better solution to handle this situation?
Related
I have a progressive web app which works as intended.
But now I want to know how to check if the site has changed (if the user is online) so the user gets the newest version.
Right now I need to hard reload or wait till the service worker does this automatically.
I've checked many sites including
https://developers.google.com/web/tools/workbox/modules/workbox-build#full_generatesw_config
but could not find an answer.
How can I archive that? E.g using navigator.serviceWorker.
Everytime I deploy an update to our web application customers ring in with issues where their browser hasnt picked up that index.html has changed and since the name of the .js file has changed they run into errors. Presumably because their index.html still points to the old javascript file which no longer exists.
What is the correct way to ensure that users always get the latest version when the system is updated.
We have a HTML5 + AngularJS web application. It uses WebPack to bundle the vendor and app javascript into two js files. The files contain a hashname to ensure they are different once released.
Some other information
I can never replicate this issue locally (and by that I mean in debug, on our staging site or our production site)
We use CloudFlare but purge the entire cache after release
We have a mechanism in JS that checks on page load or every 5 minutes to see if the version of our API has changed, and if so show up a "Please refresh your browser" message. Clicking this runs window.location.reload(true);
Our backend is IIS
If you need users to pick up the latest index.html when they load your site immediately after you've updated the file, make index.html non-cacheable. That will mean the browser, CloudFlare, and any intermediate proxies aren't allowed to cache it, and that one file will always be served from your canonical server.
Naturally, that has a traffic and latency impact (for you and them), but if that's really your requirement, I don't see any other option.
There are spins on this. It might not be index.html itself that isn't cacheable, you could insert another resource (a tiny JavaScript file that writes out the correct script tags) if index.html is really big and it's important to cache it, etc. But if you need the change picked up immediately, you'll need a non-cacheable resource that identifies the change.
I was trying to make an offline web app using ServiceWorker to cache the web requests. But I included sw.js in the cached file list.
Have I just broken my web app for all time for those who loaded my app already, or is there any way to recover? If I release a fixed sw.js file, I'm worried that my my users aren't getting the updated version, because they are using the cached sw.js...
Yes and no. You have broken it for some time but not forever.
Both Chrome and Firefox have implemented an automatic refresh interval of ~24 hours. You may read more about it from here.
This is still tricky, though, since some users might be using an older browser that doesn't automatically check for SW.js updates from the network. What could be done in that situation is not completely clear to me. If someone knows, please comment and I'll update this answer to include all the information.
I've red in many articles that service worker automatically detects if there's a change in its js (mine is 'service-worker.js')
http://www.html5rocks.com/en/tutorials/service-worker/introduction/
I already registered and see the status in chrome://serviceworker-internals/.
The problem is whenever i change the service-worker.js, it doesn't detect the change when I go to the scope url (mine is 'localhost/dashboard').
The weird thing is when I visit the service-worker.js (localhost/service-worker.js) , then visit the scope url, it now detects the change and I see 2 service workers in chrome://serviceworker-internals/. One has running status and the other one has 'installed' status. I presume that this is correct but why do i still need to go to the js file?
Is this a server side problem or cache problem? I tried clearing the cache but the problem keeps getting back.
If you make a change to your service worker, then reloading the page won't kill the old one and activate the new one.
You need to go to the Service Workers section in the dev tool, and checking 'Update on reload'.
Or go to about:blank and then hard refresh with cmd+r
I suggest you to use Chrome Canary for debugging service workers.
Hope it helps.
Is it possible to find out when a user installed a Chrome extension?
I know it's possible to save the date as local data when the user first uses the extension. I'm wondering if it's possible to get the date when the extension didn't store this data.
This is closest possible API: management, ExtensionInfo object.
Since it does not provide this information - no, this is not possible.
You can try different approach instead of requesting "management" permission from the users (they may reject the app only because this permission if it's not connection with application purpose). You can use chrome.storage (https://developer.chrome.com/extensions/storage) API in you background / event page. Both will run just after installation complete. Then you can read some flag using chrome.storage API and if it isn't set it means that the app has been installed a moment ago (the script will run just after installation finish). User can't delete this data so it is reliable. After installation just set the flag so it will not recognize installation again.
If you use background page you just need to call it anywhere in the file. If you use Event page you need to register an event chrome.runtime.onInstalled (https://developer.chrome.com/extensions/runtime#event-onInstalled).
Note that the onInstalled event is fired after app update or chrome update so you can't treat it as a one time registration event.