RESOLVED FIXED Bug 190269
IOS 12 - Service worker cache not shared when added to homescreen
https://bugs.webkit.org/show_bug.cgi?id=190269
Summary IOS 12 - Service worker cache not shared when added to homescreen
corne.alant
Reported 2018-10-03 16:58:26 PDT
On IOS 12, it appears the service worker is shared between Safari and the "Add to Homescreen" Webview but not the cache. That means that once user actions "add to home screen" they will have a service worker installed but not the expected cache. As many service worker projects do, they precache assets once the service worker is installed. After a user adds the PWA to homescreen, it appears the service worker is still installed but the cache is no longer shared. This behavior is inconsistent with other browsers and the previous versions of IOS. An issue has also been logged against Workbox JS, a third party library that no longer works on IOS 12 as a consequence of this inconsistency. https://github.com/GoogleChrome/workbox/issues/1672
Attachments
Patch (3.14 KB, patch)
2018-10-09 14:07 PDT, youenn fablet
no flags
Patch (3.57 KB, patch)
2018-10-09 14:12 PDT, youenn fablet
no flags
Patch (12.87 KB, patch)
2018-10-09 16:48 PDT, youenn fablet
no flags
Fix Win (12.96 KB, patch)
2018-10-09 20:33 PDT, youenn fablet
no flags
Patch (14.66 KB, patch)
2018-10-10 07:38 PDT, youenn fablet
no flags
Patch (15.96 KB, patch)
2018-10-11 09:55 PDT, youenn fablet
no flags
Patch for landing (15.91 KB, patch)
2018-10-11 16:34 PDT, youenn fablet
no flags
Chris Dumez
Comment 1 2018-10-04 08:56:23 PDT
Youenn should take a look I believe.
Radar WebKit Bug Importer
Comment 2 2018-10-04 08:57:01 PDT
youenn fablet
Comment 3 2018-10-04 11:51:39 PDT
Will take a look tomorrow.
youenn fablet
Comment 4 2018-10-09 13:58:13 PDT
I reproduced the issue on MobileSafari. Doing some debugging, the following happens: - NetworkProcess wants to create a cache storage engine - NetworkProcess asks UIProcess where to store data based on the session ID - NetworkProcessProxy on UIProcess has no WebsiteDataStore for that session ID - NetworkProcessProxy returns ephemeral parameters Looking at the session ID, it is the default session so probably what happens is that at NetworkProcessProxy creation time, WebProcessPool default WebsiteDataStore is not set yet so we do not keep it in the list of NetworkProcessProxy sessions.
youenn fablet
Comment 5 2018-10-09 14:07:00 PDT
youenn fablet
Comment 6 2018-10-09 14:07:22 PDT
(In reply to youenn fablet from comment #5) > Created attachment 351910 [details] > Patch API test missing.
youenn fablet
Comment 7 2018-10-09 14:12:20 PDT
youenn fablet
Comment 8 2018-10-09 16:48:49 PDT
EWS Watchlist
Comment 9 2018-10-09 16:52:05 PDT
Attachment 351926 [details] did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:197: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:222: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] Total errors found: 2 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
youenn fablet
Comment 10 2018-10-09 20:33:05 PDT
EWS Watchlist
Comment 11 2018-10-09 20:34:16 PDT
Attachment 351939 [details] did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:197: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:222: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] Total errors found: 2 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
youenn fablet
Comment 12 2018-10-10 07:38:41 PDT
EWS Watchlist
Comment 13 2018-10-10 07:40:34 PDT
Attachment 351959 [details] did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:197: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:222: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] Total errors found: 2 in 12 files If any of these errors are false positives, please file a bug against check-webkit-style.
youenn fablet
Comment 14 2018-10-10 14:22:26 PDT
Comment on attachment 351959 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=351959&action=review > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:639 > + auto quota = m_processPool.websiteDataStore() ? m_processPool.websiteDataStore()->websiteDataStore().cacheStoragePerOriginQuota() : WebsiteDataStore::defaultCacheStoragePerOriginQuota; Could be simplified here to directly use WebsiteDataStore::defaultCacheStoragePerOriginQuota...
Chris Dumez
Comment 15 2018-10-10 14:23:06 PDT
Comment on attachment 351959 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=351959&action=review > Source/WebKit/UIProcess/API/APIWebsiteDataStore.cpp:50 > + adoptRef(*globalDefaultDataStore); Why not simply delete globalDefaultDataStore; ? > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:632 > + ASSERT(sessionID == PAL::SessionID::defaultSessionID()); I do not fully understand this fix. I am 90% sure that home screen apps (Web.app) do not use the default session ID. Why wouldn't this hit this assertion?
youenn fablet
Comment 16 2018-10-10 15:19:54 PDT
(In reply to Chris Dumez from comment #15) > Comment on attachment 351959 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=351959&action=review > > > Source/WebKit/UIProcess/API/APIWebsiteDataStore.cpp:50 > > + adoptRef(*globalDefaultDataStore); > > Why not simply delete globalDefaultDataStore; ? Some other code might have refed the globalDefaultDataStore. We are leaking the ref above, so adoptRef is the exact inverse operation. > > > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:632 > > + ASSERT(sessionID == PAL::SessionID::defaultSessionID()); > > I do not fully understand this fix. I am 90% sure that home screen apps > (Web.app) do not use the default session ID. Why wouldn't this hit this > assertion? Web.app networking process always get the right cache storage path so Web.app behavior should be unchanged. Safari is using the default session ID and its networking process does not always get the right cache storage path in that case. This happens when the web process pool spins the network process before any web page is created and before the default website data store is created.
Alex Christensen
Comment 17 2018-10-10 18:22:04 PDT
Comment on attachment 351959 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=351959&action=review >>> Source/WebKit/UIProcess/API/APIWebsiteDataStore.cpp:50 >>> + adoptRef(*globalDefaultDataStore); >> >> Why not simply delete globalDefaultDataStore; ? > > Some other code might have refed the globalDefaultDataStore. > We are leaking the ref above, so adoptRef is the exact inverse operation. This is what static NeverDestroyed<RefPtr<WebsiteDataStore>> is for. Setting that to nullptr will be much less strange than this.
youenn fablet
Comment 18 2018-10-11 09:55:09 PDT
EWS Watchlist
Comment 19 2018-10-11 09:57:49 PDT
Attachment 352051 [details] did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:197: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:222: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] Total errors found: 2 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
Alex Christensen
Comment 20 2018-10-11 16:18:13 PDT
Comment on attachment 352051 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=352051&action=review > Source/WebKit/UIProcess/API/APIWebsiteDataStore.cpp:57 > + auto& store = globalDefaultDataStore(); > + if (!store) > + return; > + store = nullptr; This could just be replaced by one line: globalDefaultDataStore() = nullptr;
youenn fablet
Comment 21 2018-10-11 16:34:07 PDT
Created attachment 352101 [details] Patch for landing
EWS Watchlist
Comment 22 2018-10-11 16:35:09 PDT
Attachment 352101 [details] did not pass style-queue: ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:197: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] ERROR: Tools/TestWebKitAPI/Tests/WebKitCocoa/ServiceWorkerBasic.mm:222: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use concatenation instead". [readability/multiline_string] [5] Total errors found: 2 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
WebKit Commit Bot
Comment 23 2018-10-11 18:33:36 PDT
Comment on attachment 352101 [details] Patch for landing Clearing flags on attachment: 352101 Committed r237060: <https://trac.webkit.org/changeset/237060>
WebKit Commit Bot
Comment 24 2018-10-11 18:33:38 PDT
All reviewed patches have been landed. Closing bug.
Arthur
Comment 25 2018-11-06 13:16:17 PST
Hello. Has it been landed in iOS 12.1? I actually thought it did because everything worked when I updated from 12.0.1, but now it doesn't after I restarted the phone. I just tried in the 12.1 emulator and it doesn't work there too. I actually saw the same thing when upgraded from 11.4.1 to 12. It worked at first and then suddenly stopped. Then I just didn't realize that it was because of a restart. Now I do.
Edoardo Cavazza
Comment 26 2018-11-08 03:38:14 PST
I con confirm that it still doesn't work in iOS 12.1
Chris Fantino
Comment 27 2018-11-08 07:17:12 PST
Not working in IOS 12.1
tmdoit
Comment 28 2018-11-23 16:34:55 PST
Same here, couldn't get it work on 12.1
tmdoit
Comment 29 2018-11-27 03:10:09 PST
Same here on iOS 12.01.
Chris Dumez
Comment 30 2018-11-27 09:09:04 PST
The fix did not ship in 12.1 so it is not surprising you are still experiencing the issue. Please give it some time.
tmdoit
Comment 31 2018-11-29 09:58:45 PST
Chris Dumez thanks for your reply. Is the below issue related? "iOS 12 Safari does not support the offline feature of some PWAs (Progressive Web App). It seems like Safari does not cache resources in those web apps properly. For example, the following PWAs cannot work offline in iOS 12 and 12.1, but they all work perfectly in Chrome on Android or Windows: The Air Horner PWA that is used by google to demonstrate Service Worker: Air Horner And these two: 2048 puzzle Voice Memos Steps to reproduce (100% reproducible): visit the PWA with Safari (iOS 12 or 12.1) close the PWA tab in Safari push home button on iPhone to set Safari to background push the iPhone power button to turn off screen push the iPhone power button again to wake up the phone turn off all the network connection from the iPhone control center (both wifi and cellular) open Safari, visit PWA again --> the web app fail to load This has been bothering me for a long time, as my own web app also has the similar issue - works fine in Chrome on Android / Windows but only fails on iOS 12 Safari. Any idea what special in iOS 12 Safari? Thank you very much!" Source: https://stackoverflow.com/questions/53439379/ios-12-does-not-support-offline-feature-of-some-pwas/53495939#53495939
tmdoit
Comment 32 2018-11-29 11:47:15 PST
(In reply to tmdoit from comment #31) > Chris Dumez thanks for your reply. > > Is the below issue related? > "iOS 12 Safari does not support the offline feature of some PWAs > (Progressive Web App). It seems like Safari does not cache resources in > those web apps properly. > > For example, the following PWAs cannot work offline in iOS 12 and 12.1, but > they all work perfectly in Chrome on Android or Windows: > > The Air Horner PWA that is used by google to demonstrate Service Worker: > Air Horner > > And these two: > 2048 puzzle > Voice Memos > > Steps to reproduce (100% reproducible): > > visit the PWA with Safari (iOS 12 or 12.1) > close the PWA tab in Safari > push home button on iPhone to set Safari to background > push the iPhone power button to turn off screen > push the iPhone power button again to wake up the phone > turn off all the network connection from the iPhone control center (both > wifi and cellular) > open Safari, visit PWA again --> the web app fail to load > This has been bothering me for a long time, as my own web app also has the > similar issue - works fine in Chrome on Android / Windows but only fails on > iOS 12 Safari. Any idea what special in iOS 12 Safari? Thank you very much!" > > Source: > https://stackoverflow.com/questions/53439379/ios-12-does-not-support-offline- > feature-of-some-pwas/53495939#53495939 Here is new issue opened https://bugs.webkit.org/show_bug.cgi?id=192166.
Etienne Maheu
Comment 33 2018-12-03 11:26:34 PST
@tmdoit based on the repro steps on your comment, I devised a test that appear to confirm that your issue is link to this bug. Here are the actual test: Repro with a homescreen app 1. visit the PWA with Safari (iOS 12 or 12.1) 2. add the app to your homescreen. 2. close the PWA tab in Safari 3. push home button on iPhone to set Safari to background 4. push the iPhone power button to turn off screen 5. push the iPhone power button again to wake up the phone 6. turn off all the network connection from the iPhone control center (both wifi and cellular) 7. open the app via your homescreen --> the web app fail to load Additional steps to force the SW to cache the app on the right AppId 8. close the app via the app manager 9. go to Setting > Safari > Clear History and Website Data 10. turn on the network connection 11. open the app via your homescreen --> the web app loads from the server and install the service worker Additional steps to check for offline support 12. turn off all the network connection 13. quit the app 14. push the iPhone power button to turn off screen 15. push the iPhone power button again to wake up the phone 16. open the app via your homescreen --> the web app loads from the local cache
tmdoit
Comment 34 2018-12-03 14:32:55 PST
Etienne Maheu: thanks for your response, It's working as you described. So we are waiting for the patched version of Safari.
youenn fablet
Comment 35 2019-01-04 10:23:43 PST
*** Bug 192166 has been marked as a duplicate of this bug. ***
Edoardo Cavazza
Comment 36 2019-03-26 05:49:32 PDT
Still not landed in iOS 12.2. Does someone have informations about the release version of this patch?
Ryosuke Niwa
Comment 37 2019-04-16 16:26:23 PDT
(In reply to Edoardo Cavazza from comment #36) > Still not landed in iOS 12.2. Does someone have informations about the > release version of this patch? This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS 12.1. Could you please file a new bug with the detailed description as to what issue you're seeing?
Etienne Maheu
Comment 38 2019-06-17 07:01:38 PDT
(In reply to Ryosuke Niwa from comment #37) > (In reply to Edoardo Cavazza from comment #36) > > Still not landed in iOS 12.2. Does someone have informations about the > > release version of this patch? > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > 12.1. > > Could you please file a new bug with the detailed description as to what > issue you're seeing? I would like to confirm that the test I previously mentioned in this thread is now passing in iOS 12.2. I too would tend to believe that @EdoardoCavazza is experiencing a different issue.
Marlon Maxwel
Comment 39 2019-06-21 09:30:02 PDT
(In reply to Ryosuke Niwa from comment #37) > (In reply to Edoardo Cavazza from comment #36) > > Still not landed in iOS 12.2. Does someone have informations about the > > release version of this patch? > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > 12.1. > > Could you please file a new bug with the detailed description as to what > issue you're seeing? Has the problem really been fixed? We are currently using iOS 12.3.1 and the problem still happens. In Safari it works correctly, but when you're using PWA it does not work. There are behavioral differences between Safari and PWA on iOS. Our scenario: - Open the application in Safari; - We installed PWA on iOS; - We close the Safari; - We release a new version of the application; - PWA continues to use old asset cache - precache (apparently the serviceWorker flow in PWA is different from normal); - PWA is obsolete and does not update to the new assets in any way; - We reboot the Iphone and PWA works with the new assets; This stream works properly on Chrome, Firefox, Android, Safari, but the PWA installed on iOS does not work at all.
youenn fablet
Comment 40 2019-06-21 09:33:29 PDT
(In reply to Marlon Maxwel from comment #39) > (In reply to Ryosuke Niwa from comment #37) > > (In reply to Edoardo Cavazza from comment #36) > > > Still not landed in iOS 12.2. Does someone have informations about the > > > release version of this patch? > > > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > > 12.1. > > > > Could you please file a new bug with the detailed description as to what > > issue you're seeing? > > > Has the problem really been fixed? > > We are currently using iOS 12.3.1 and the problem still happens. > > In Safari it works correctly, but when you're using PWA it does not work. > There are behavioral differences between Safari and PWA on iOS. > > Our scenario: > - Open the application in Safari; > - We installed PWA on iOS; > - We close the Safari; > - We release a new version of the application; > - PWA continues to use old asset cache - precache (apparently the > serviceWorker flow in PWA is different from normal); > - PWA is obsolete and does not update to the new assets in any way; > - We reboot the Iphone and PWA works with the new assets; This is probably a different bug, could you file another bug?
Marlon Maxwel
Comment 41 2019-06-21 10:09:38 PDT
(In reply to youenn fablet from comment #40) > (In reply to Marlon Maxwel from comment #39) > > (In reply to Ryosuke Niwa from comment #37) > > > (In reply to Edoardo Cavazza from comment #36) > > > > Still not landed in iOS 12.2. Does someone have informations about the > > > > release version of this patch? > > > > > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > > > 12.1. > > > > > > Could you please file a new bug with the detailed description as to what > > > issue you're seeing? > > > > > > Has the problem really been fixed? > > > > We are currently using iOS 12.3.1 and the problem still happens. > > > > In Safari it works correctly, but when you're using PWA it does not work. > > There are behavioral differences between Safari and PWA on iOS. > > > > Our scenario: > > - Open the application in Safari; > > - We installed PWA on iOS; > > - We close the Safari; > > - We release a new version of the application; > > - PWA continues to use old asset cache - precache (apparently the > > serviceWorker flow in PWA is different from normal); > > - PWA is obsolete and does not update to the new assets in any way; > > - We reboot the Iphone and PWA works with the new assets; > > This is probably a different bug, could you file another bug? Open this bug: https://bugs.webkit.org/show_bug.cgi?id=199110
Etienne Maheu
Comment 42 2019-06-21 10:40:46 PDT
(In reply to Marlon Maxwel from comment #41) > (In reply to youenn fablet from comment #40) > > (In reply to Marlon Maxwel from comment #39) > > > (In reply to Ryosuke Niwa from comment #37) > > > > (In reply to Edoardo Cavazza from comment #36) > > > > > Still not landed in iOS 12.2. Does someone have informations about the > > > > > release version of this patch? > > > > > > > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > > > > 12.1. > > > > > > > > Could you please file a new bug with the detailed description as to what > > > > issue you're seeing? > > > > > > > > > Has the problem really been fixed? > > > > > > We are currently using iOS 12.3.1 and the problem still happens. > > > > > > In Safari it works correctly, but when you're using PWA it does not work. > > > There are behavioral differences between Safari and PWA on iOS. > > > > > > Our scenario: > > > - Open the application in Safari; > > > - We installed PWA on iOS; > > > - We close the Safari; > > > - We release a new version of the application; > > > - PWA continues to use old asset cache - precache (apparently the > > > serviceWorker flow in PWA is different from normal); > > > - PWA is obsolete and does not update to the new assets in any way; > > > - We reboot the Iphone and PWA works with the new assets; > > > > This is probably a different bug, could you file another bug? > > > Open this bug: https://bugs.webkit.org/show_bug.cgi?id=199110 This is a different issue. The original problem here was that causing the PWA installed from the home-screen to never cache anything which prevent it from working offline. The issue you are describing now is something I discussed on the VueJs and Google Workbox github pages. There is a workaround that you can use with Google Workbox which is to use the "skipWaiting" option to force the SW to restart as soon as it receives an update. You could take a look at how workbox handle this option and replicate it in your SW code.
Marlon Maxwel
Comment 43 2019-06-21 13:19:35 PDT
(In reply to Etienne Maheu from comment #42) > (In reply to Marlon Maxwel from comment #41) > > (In reply to youenn fablet from comment #40) > > > (In reply to Marlon Maxwel from comment #39) > > > > (In reply to Ryosuke Niwa from comment #37) > > > > > (In reply to Edoardo Cavazza from comment #36) > > > > > > Still not landed in iOS 12.2. Does someone have informations about the > > > > > > release version of this patch? > > > > > > > > > > This fix is included in iOS 12.1.1 and iOS 12.1.2, and most definitely iOS > > > > > 12.1. > > > > > > > > > > Could you please file a new bug with the detailed description as to what > > > > > issue you're seeing? > > > > > > > > > > > > Has the problem really been fixed? > > > > > > > > We are currently using iOS 12.3.1 and the problem still happens. > > > > > > > > In Safari it works correctly, but when you're using PWA it does not work. > > > > There are behavioral differences between Safari and PWA on iOS. > > > > > > > > Our scenario: > > > > - Open the application in Safari; > > > > - We installed PWA on iOS; > > > > - We close the Safari; > > > > - We release a new version of the application; > > > > - PWA continues to use old asset cache - precache (apparently the > > > > serviceWorker flow in PWA is different from normal); > > > > - PWA is obsolete and does not update to the new assets in any way; > > > > - We reboot the Iphone and PWA works with the new assets; > > > > > > This is probably a different bug, could you file another bug? > > > > > > Open this bug: https://bugs.webkit.org/show_bug.cgi?id=199110 > > This is a different issue. The original problem here was that causing the > PWA installed from the home-screen to never cache anything which prevent it > from working offline. > > The issue you are describing now is something I discussed on the VueJs and > Google Workbox github pages. There is a workaround that you can use with > Google Workbox which is to use the "skipWaiting" option to force the SW to > restart as soon as it receives an update. You could take a look at how > workbox handle this option and replicate it in your SW code. 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.
Note You need to log in before you can comment on or make changes to this bug.