Bug 217722
Summary: | [Webkit 14] : Caching undefined on subsequent instantiation | ||
---|---|---|---|
Product: | WebKit | Reporter: | Chad <chad.nehemiah94> |
Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | bfulgham, corbanbrook, katherine_cheney, sean, webkit-bug-importer, wilander, youennf |
Priority: | P1 | Keywords: | InRadar |
Version: | Safari 14 | ||
Hardware: | iPhone / iPad | ||
OS: | Other |
Chad
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/70335075>
youenn fablet
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?
Chad
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.
youenn fablet
(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?
Chad
window.isSecureContext returns true but window.Credential is undefined.
Chad
(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.
Kate Cheney
Hi Chad. Is this issue happening for all pages, or only service worker loaded/controlled pages?
Chad
(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.
Corban
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.
Kate Cheney
(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/?
Corban
(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.
Sean
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.