Summary: | PWA in iOS use old assets after publish new servicerWorker/assets | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Marlon Maxwel <marlonmleite> | ||||||
Component: | WebKit2 | Assignee: | youenn fablet <youennf> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Critical | CC: | achristensen, beidson, cdumez, chrisheaththomas, etienne.maheu, hearcomestreble, ik, jorgen, nicolas, rniwa, tiago.wippel, webkit-bug-importer, webkit, w.kujawski1, youennf | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | iPhone / iPad | ||||||||
OS: | iOS 12 | ||||||||
Attachments: |
|
Description
Marlon Maxwel
2019-06-21 10:08:39 PDT
Thanks for the report. IIUC, the PWA is running (Safari is not) while a new version of the application is being released. The expected behavior is for the PWA service worker to update itself and its cache assets as well. This only happens when relaunching the PWA after reboot. If you do the same flow with Safari, the service worker and its cache assets are updated as expected. Is that correct? If you have a live repro case that you can share (either privately or publicly) that may help. (In reply to youenn fablet from comment #2) > Thanks for the report. > IIUC, the PWA is running (Safari is not) while a new version of the > application is being released. > The expected behavior is for the PWA service worker to update itself and its > cache assets as well. This only happens when relaunching the PWA after > reboot. > If you do the same flow with Safari, the service worker and its cache assets > are updated as expected. > Is that correct? > > If you have a live repro case that you can share (either privately or > publicly) that may help. Yes correct, in Safari the service worker and its cache assets are updated as expected. In Android, the PWA don't require a phone reboot to apply new release/assets. This is good for user receive new released version/assets with more frequency. And this is good idea for iOS users with PWA. I will recreate this scenario as soon as possible and publish it here. Because my app it's in homologation and not available for the public access in the moment, only in my company. Let us continue this discussion in this thread instead. ================================================================= > Yes, I understand this problem. > > The problem you mentioned that you discussed in the communiques, I also encountered these discussions but don't work. > > The skipWaiting function does not work on iOS equal it works correctly on all. Were you able to make updates work correctly on iOS only with skipWaiting? > > We applied the solution using skipWaiting combining with the worker's controllerchange to update, but it does not work in any way on iOS and so we opened the BUG I mentioned above. > > I would be happy to see 1 example of everything working on iOS, but using the implementations of workbox, create-react-app, vue-cli, google... none worked. I think I understand your problem better now. What you are describing happens because iOS will never unload the PWA, so even with "skipWaiting" set, which will refresh the cache properly, the app itself never gets to restart. Assuming that you are using the "skipWaiting" trick, you will also want to implement this code in your head html tag: https://gist.github.com/kawazoe/fa3b5a3c998d16871ffb9e2fd721cb4b The gist contain a minified and unminified version of a script that will detect application version changes and automatically trigger a page refresh when they happen. This code parses the content of the "service-worker.js" file that is generated by Google Workbox to look for a file called "precache-manifest.*.js". The star here correspond to a unique hash that will change every time your app updates. This script uses this hash as a site version and stores it as "pmv" in local storage. If the version is different from the version stored in localstorage, this script will refresh the page. This works because the "service-worker.js" file is requested in a way that will always bypass caches. This is truly a hack, a workaround, to get this working on iOS. Unfortunately, it can make the app "blink" once after an update since your PWA will not wait for this call to finish before loading. Also, you will need to either reboot (if you find it to work) or clear the safari cache after you make this change to ensure that the html file that your device cached include the fix. I am running this in production on one of my apps and it has been working fine for over 6 months now. (In reply to youenn fablet from comment #2) > Thanks for the report. > IIUC, the PWA is running (Safari is not) while a new version of the > application is being released. > The expected behavior is for the PWA service worker to update itself and its > cache assets as well. This only happens when relaunching the PWA after > reboot. > If you do the same flow with Safari, the service worker and its cache assets > are updated as expected. > Is that correct? > > If you have a live repro case that you can share (either privately or > publicly) that may help. I have made available the repository with demo and instructions for deployment and simulation of the bug. I tested the demo code and it has the bug as reported. See: https://github.com/marlonmleite/bug-ios-sw I have the same problem with cache in my PWA app. When new content is available app doesn't refresh even with "networkFirst" option set in workbox (I use Vue CLI with PWA add-on). Only restarting iOS makes app to refresh the cache. It was working previously but for some time it isn't. iOS 12.3.1, iPhone 8 (In reply to Jan Nowak from comment #6) > I have the same problem with cache in my PWA app. When new content is > available app doesn't refresh even with "networkFirst" option set in workbox > (I use Vue CLI with PWA add-on). Only restarting iOS makes app to refresh > the cache. It was working previously but for some time it isn't. > > iOS 12.3.1, iPhone 8 While this issue isn't solved I created a workround with the solution, see more: https://gist.github.com/kawazoe/fa3b5a3c998d16871ffb9e2fd721cb4b#gistcomment-2953706 Any news on this? iPadOS 14.4 seems to have made this on issue in Safari, Chrome and web apps. I need to reboot to force new files to come in. My headers: ``` <filesMatch "\.(html|htm|js|css|less|json)$"> FileETag None <ifModule mod_headers.c> Header unset ETag Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" Header set Pragma "no-cache" Header set Expires "Wed, 3 Oct 1983 06:00:00 GMT" Header set Vary: * </ifModule> </filesMatch> ``` Nevermind my previous comment. I had some css that wasn't being picked up and it turns out that Safari on iPad Mini's doesn't act like it's a desktop browser. (In reply to youenn fablet from comment #2) > Thanks for the report. > IIUC, the PWA is running (Safari is not) while a new version of the > application is being released. > The expected behavior is for the PWA service worker to update itself and its > cache assets as well. This only happens when relaunching the PWA after > reboot. > If you do the same flow with Safari, the service worker and its cache assets > are updated as expected. > Is that correct? > > If you have a live repro case that you can share (either privately or > publicly) that may help. The PWA does not have to be "running while a new version of the application is being released" for this bug to manifest. The PWA just needs to be have been installed (added to the Homescreen). Without the workarounds linked by others in the comments, this bug is a blocker to deploying a PWA on iOS. Created attachment 458585 [details]
Patch
Created attachment 458677 [details]
Patch
I tried reproing the issue locally and the case where things go bad is when network process is stopped between two runs of the application. In that case, the waiting service worker never gets to activating/activated and we do not update the service worker scripts. Committed r293676 (250178@main): <https://commits.webkit.org/250178@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 458677 [details]. |