IOS 12 - Service worker cache not shared when added to homescreen

• Component: WebKit2
• Status: RESOLVED FIXED

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

[Chris Dumez]

Youenn should take a look I believe.

[Radar WebKit Bug Importer]

<rdar://problem/45009961>

[youenn fablet]

Will take a look tomorrow.

[youenn fablet]

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]

Created attachment 351910 [details]
Patch

[youenn fablet]

(In reply to youenn fablet from comment #5)
> Created attachment 351910 [details]
> Patch

API test missing.

[youenn fablet]

Created attachment 351912 [details]
Patch

[youenn fablet]

Created attachment 351926 [details]
Patch

[EWS Watchlist]

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]

Created attachment 351939 [details]
Fix Win

[EWS Watchlist]

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]

Created attachment 351959 [details]
Patch

[EWS Watchlist]

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 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 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]

(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 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]

Created attachment 352051 [details]
Patch

[EWS Watchlist]

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 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]

Created attachment 352101 [details]
Patch for landing

[EWS Watchlist]

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 on attachment 352101 [details]
Patch for landing

Clearing flags on attachment: 352101

Committed r237060: <https://trac.webkit.org/changeset/237060>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Arthur]

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]

I con confirm that it still doesn't work in iOS 12.1

[Chris Fantino]

Not working in IOS 12.1

[tmdoit]

Same here, couldn't get it work on 12.1

[tmdoit]

Same here on iOS 12.01.

[Chris Dumez]

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]

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]

(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]

@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]

Etienne Maheu: thanks for your response, It's working as you described.

So we are waiting for the patched version of Safari.

[youenn fablet]

*** Bug 192166 has been marked as a duplicate of this bug. ***

[Edoardo Cavazza]

Still not landed in iOS 12.2. Does someone have informations about the release version of this patch?

[Ryosuke Niwa]

(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]

(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]

(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]

(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]

(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]

(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]

(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.