Runtime caching for custom url pattern does not work in Safari

Issue Custom cached url (image from firebase storage) does not work in Safari. While Chrome and Firefox get the image from cache and therefore also work in offline mode, Safari (desktop/mobile) keeps downloading the image every time and if offline, not find anything anymore obviously.

Library Affected: workbox-sw, workbox-build, workbox-webpack-plugin etc. (default vue quasar workbox plugin)

Browser & Platform: Safari (desktop Version 13.0.3 (15608.3.10.1.4) / mobile iOS 13.1.3)

I’m using the workbox plugin for quasar. The following is a snippet from quasar.conf file managing the pwa and workbox options. Anyway, I don’t think my issue is related to quasar or the plugin specifically but to the compatibility between workbox and safari.

  pwa: {
      workboxPluginMode: 'GenerateSW',
      workboxOptions:  {
        clientsClaim: true,
        navigateFallback: '/index.html',
        runtimeCaching: [
          {
            urlPattern: new RegExp('media&token'),
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'brochures-cache',
              cacheableResponse: {
                statuses: [0, 200]
              },
              fetchOptions: {
                mode: 'no-cors'
              }
            }
          },
          {
            urlPattern: '/',
            handler: 'NetworkFirst'
          }
        ],
      },
  }

[jeffposnick]

Following the steps that you provided with the https://github.com/alexeigs/debugging repo and swapping in RegExp('^https://firebasestorage\.googleapis\.com/.*media&token') as the RegExp in your GenerateSW config leads to something that works fine offline across all browsers, in my local testing.

I took these screenshots of Safari’s DevTools (both the SW version and the main page version) while offline, and the PNG response successfully comes from the SW from the perspective of the main page:

The logging in the SW DevTools shows that the StaleWhileRevalidate strategy is being used to handle the request and it successfully generates a response from the cache (even though “revalidate” step via the network fails):

So… I’m not actually able to reproduce any issues, and I do think that switching the RegExp to ensure that it matches the start of the third-party URLs is necessary.

[jeffposnick]

Happy that you got things sorted! (And apologies that the cross-origin routing behavior can be less than intuitive without logging enabled.)