Bug 217722 - [Webkit 14] : Caching undefined on subsequent instantiation
Summary: [Webkit 14] : Caching undefined on subsequent instantiation
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: Safari 14
Hardware: iPhone / iPad Other
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-10-14 11:52 PDT by Chad
Modified: 2021-03-05 15:25 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chad 2020-10-14 11:52:57 PDT
We are utilizing App-Bound domains with a webview in our react native app.
we set  webViewConfiguration.limitsNavigationsToAppBoundDomains = YES; via https://github.com/react-native-webview/react-native-webview , we notice that our service worker registers and thus populates our web-browser Cache on initial instantiation, but on subsequent instantiations, window.caches is undefined.
Comment 1 Radar WebKit Bug Importer 2020-10-15 07:35:57 PDT
<rdar://problem/70335075>
Comment 2 youenn fablet 2020-10-15 07:39:31 PDT
What I understand:
- you register a service worker. As part of this service worker, caches is there and you populate it
- on a web page, window.caches is undefined.

One possibility is that the web page is not SecureContext.
Can you verify this? Has this web page navigator.serviceWorker but not window.caches?
Comment 3 Chad 2020-10-15 09:13:14 PDT
Thanks for the assistance Youenn,

Yes, your understanding is correct. What I would also like to add for clarification is that window.caches exists on the first load of the Webview but not on subsequent loads. Navigator.serviceWorker remains consistent.
Comment 4 youenn fablet 2020-10-15 09:28:48 PDT
(In reply to Chad from comment #3)
> Thanks for the assistance Youenn,
> 
> Yes, your understanding is correct. What I would also like to add for
> clarification is that window.caches exists on the first load of the Webview
> but not on subsequent loads. Navigator.serviceWorker remains consistent.

What about other window SecureContext properties like window.Credential?
What about window.isSecureContext?
Comment 5 Chad 2020-10-15 09:50:54 PDT
window.isSecureContext returns true but window.Credential is undefined.
Comment 6 Chad 2020-10-16 07:31:02 PDT
(In reply to youenn fablet from comment #4)
> (In reply to Chad from comment #3)
> > Thanks for the assistance Youenn,
> > 
> > Yes, your understanding is correct. What I would also like to add for
> > clarification is that window.caches exists on the first load of the Webview
> > but not on subsequent loads. Navigator.serviceWorker remains consistent.
> 
> What about other window SecureContext properties like window.Credential?
> What about window.isSecureContext?

window.isSecureContext returns true but window.Credential is undefined.
Comment 7 Kate Cheney 2020-10-16 07:48:41 PDT
Hi Chad. Is this issue happening for all pages, or only service worker loaded/controlled pages?
Comment 8 Chad 2020-10-16 08:16:22 PDT
(In reply to katherine_cheney from comment #7)
> Hi Chad. Is this issue happening for all pages, or only service worker
> loaded/controlled pages?

Hi kate, 

Unfortunately we don't have any pages which are not controlled by the service worker scope, since it is set to the root of the domain. So this issue is replicable on all pages.
Comment 9 Corban 2020-10-16 08:36:40 PDT
Hello, thought I would add some further context to our individual setup.

We have a web based game (WebGL) and are using the ServiceWorker and Cache Storage API to cache assets, mainly the textures and sounds used in the game.

This is working great in desktop and mobile in Safari and other browsers. Also works great on iOS when added to home screen in PWA mode.

However we have an iOS native app (react-native) which adds some additional functionality but mainly serves to wrap the WebGL game loaded in a webview.

On a fresh install of this iOS app, the service worker registers and can see window.caches and correctly creates the cache, we have verified that fetched files are stored in cache as well.

Then if you shutdown the app and reopen it window.caches is no longer available.

If we uninstall the app and reinstall it will work again for the first load.

The service worker scope is at the root of the domain (ie, controls all fetch requests on all pages in our webapp). We have verified that it still processes fetch requests on subsequent loads, but of course no cache is available so always fetches from network.
Comment 10 Kate Cheney 2020-10-16 15:07:30 PDT
(In reply to Corban from comment #9)
> Hello, thought I would add some further context to our individual setup.
> 
> We have a web based game (WebGL) and are using the ServiceWorker and Cache
> Storage API to cache assets, mainly the textures and sounds used in the game.
> 
> This is working great in desktop and mobile in Safari and other browsers.
> Also works great on iOS when added to home screen in PWA mode.
> 
> However we have an iOS native app (react-native) which adds some additional
> functionality but mainly serves to wrap the WebGL game loaded in a webview.
> 
> On a fresh install of this iOS app, the service worker registers and can see
> window.caches and correctly creates the cache, we have verified that fetched
> files are stored in cache as well.
> 
> Then if you shutdown the app and reopen it window.caches is no longer
> available.
> 
> If we uninstall the app and reinstall it will work again for the first load.
> 
> The service worker scope is at the root of the domain (ie, controls all
> fetch requests on all pages in our webapp). We have verified that it still
> processes fetch requests on subsequent loads, but of course no cache is
> available so always fetches from network.

Thanks for the additional info. Do you have your required domain(s) listed in the app's Info.plist under WKAppBoundDomains as is outlined in https://webkit.org/blog/10882/app-bound-domains/?
Comment 11 Corban 2020-10-19 07:33:46 PDT
(In reply to katherine_cheney from comment #10)
> (In reply to Corban from comment #9)
> > Hello, thought I would add some further context to our individual setup.
> > 
> > We have a web based game (WebGL) and are using the ServiceWorker and Cache
> > Storage API to cache assets, mainly the textures and sounds used in the game.
> > 
> > This is working great in desktop and mobile in Safari and other browsers.
> > Also works great on iOS when added to home screen in PWA mode.
> > 
> > However we have an iOS native app (react-native) which adds some additional
> > functionality but mainly serves to wrap the WebGL game loaded in a webview.
> > 
> > On a fresh install of this iOS app, the service worker registers and can see
> > window.caches and correctly creates the cache, we have verified that fetched
> > files are stored in cache as well.
> > 
> > Then if you shutdown the app and reopen it window.caches is no longer
> > available.
> > 
> > If we uninstall the app and reinstall it will work again for the first load.
> > 
> > The service worker scope is at the root of the domain (ie, controls all
> > fetch requests on all pages in our webapp). We have verified that it still
> > processes fetch requests on subsequent loads, but of course no cache is
> > available so always fetches from network.
> 
> Thanks for the additional info. Do you have your required domain(s) listed
> in the app's Info.plist under WKAppBoundDomains as is outlined in
> https://webkit.org/blog/10882/app-bound-domains/?

Yes.
Comment 12 Sean 2021-03-05 15:25:34 PST
I'll add that we are seeing also this issue, outside of a Service Worker context. Just directly accessing window.caches results in an undefined value in some cases. Based on our logging, this seems to happen more frequently in a Mobile Safari Webview, but it seems that some users are encountering this on Mobile Safari 12, 13, and 14 not in a WebView. We even have some logs showing that window.caches is sometimes undefined in Desktop Safari as well.