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
Youenn should take a look I believe.
<rdar://problem/45009961>
Will take a look tomorrow.
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.
Created attachment 351910 [details] Patch
(In reply to youenn fablet from comment #5) > Created attachment 351910 [details] > Patch API test missing.
Created attachment 351912 [details] Patch
Created attachment 351926 [details] Patch
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.
Created attachment 351939 [details] Fix Win
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.
Created attachment 351959 [details] Patch
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.
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...
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?
(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.
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.
Created attachment 352051 [details] Patch
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.
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;
Created attachment 352101 [details] Patch for landing
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.
Comment on attachment 352101 [details] Patch for landing Clearing flags on attachment: 352101 Committed r237060: <https://trac.webkit.org/changeset/237060>
All reviewed patches have been landed. Closing bug.
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.
I con confirm that it still doesn't work in iOS 12.1
Not working in IOS 12.1
Same here, couldn't get it work on 12.1
Same here on iOS 12.01.
The fix did not ship in 12.1 so it is not surprising you are still experiencing the issue. Please give it some time.
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
(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.
@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
Etienne Maheu: thanks for your response, It's working as you described. So we are waiting for the patched version of Safari.
*** Bug 192166 has been marked as a duplicate of this bug. ***
Still not landed in iOS 12.2. Does someone have informations about the release version of this patch?
(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?
(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.
(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.
(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?
(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
(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.
(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.