serviceworkers.js - Response not cacheable

Without knowing a little bit more about your website I don't think I can reproduce or debug. Were these first- or third-party requests? Your response status says 0 which can be caused by ad blockers or other internal browser network customizations.

Getting the same error after installing the module and then accessing any page offline.

How many pages are you loading with the network still enabled before trying it offline? I occasionally notice that it still requires one or two page loads to fully populate the required cache needed to serve offline pages.

Does your status report complain about drupal_http_request_fails error? If you see this error, the Service Worker pre-cache won't be populated because the server can't properly determine what CSS/JS are present on your desired offline URLs. If you have an empty array for CACHE_URLS_ASSETS = [] then you might have this problem.

Are y'all using third-party assets like a bootstrap CDN?

If possible I'd like to fix this for the upcoming 1.0 release. Could either of you determine more information based on my questions?

Yeah, I found some 404 URLs and some third party URLs like GTM library, causing this issue. But I did not find any issue with page rendering, the page is just working fine.

I think we can create a setting for admin (probably a checkbox) if it is checked then print the logs in the console.

Alright this does seem to be a bug at least when compared to the comments in our SW code which claim to cache 3rd party responses.

I encountered this while installing on a site which uses Google Fonts. It's using a basic <link> tag to include the fonts, and the SW's cacheNetworkResponse() function is throwing the exception.

We'll see what we can do to cache third-party requests that occur post-installation. Given the general tendency of sites to use fonts in this manner it would probably do a great deal to initial UX of the module if we fix this before going 1.0

Ok the problem seemed to be two-fold.

First, we were using some faulty logic to ensure only "good" responses were being added to the cache. The original intent seemed to be that any 400+ error should not be added to the cache. The code looked like this:

fetch(url).then(function (response) {
  if (response.ok) {
    // do the caching
  }
});

It seems that (maybe due to security?) third-party requests exhibit the appearance of a failed request even when the no-cors header is applied to the Request before firing, which results in an "opaque" response with status: 0, url: "", and ok: false. We already use the no-cors header in the installation code, but the response.ok conditional was preventing the response from being saved.

Furthermore, there's a catch() block which ignores this failed caching operation in order to ensure the Service Worker installs. I find this highly confusing and feel like it's a big mistake to leave that in. I've noted it in the accompanying patch with a @TODO.

Ok, onto the second issue, which is much simpler. The cacheNetworkResponse() callback that is used during most staleWhileRevalidate() operations lacked the re-request-with-no-cors-header, meaning the third-party requests never had a chance to be cached at all. However we were catching these properly and logging them to console, which is what the initial bug report demonstrates.

I've normally just been committing things but it would be really helpful if the folks who have seen this issue give the patch a try and tell me if it helps resolve the errors. You can try this one of two ways:

1. Manually add your third-party requests to the "URLs to cache on install" section under Admin > Configuration > System > PWA > Service Worker
2. Allow the Service Worker to cache them naturally by installing and then visiting a page which uses your third-party assets.

My test-case is a single tag requesting a Google Font so if there are other use-cases and CDNs which people were using it will be most helpful to test against a variety of services.

Tentatively marking as fixed. If someone tests the module containing this commit and decides it's still broken please feel free to reopen.

Crediting UN for funding my time on this issue.

Re-opening this for 8.x

Please look into the patch in #3060759: Fully working D8 version based on D7 Serviceworker which addresses this, but updates to D8 module to where it should be, i.e. same service worker functionality as the D7 version.
Closing this issue to focus efforts.