[bug/enhancement] VERY ungraceful error / bug when registering service worker without '/'

[vjancik]

Reporting here, because it affects sw-precache, even though it's service worker related directly.

I ran into very serious misbehavior in both Chrome Stable and Chrome Canary using sw-precache generated service worker with this registration code:
navigator.serviceWorker.register('service-worker.js');

In particular:

• errors on service worker registration in Application tab
  • e.g. Failed to fetch, or Unknown Error, despite the fact it registered the service worker, and even served the files from it
• unable to put breakpoints in the service worker
• if by some miracle able to put a breakdown in the service worker, unable to remove it
• even ran into infinite page load and full CPU utilization
• sometimes it worked in online mode (served stats from service worker), other times it served the navigationFallback file for all service worker intercepted requests
• however once I turned on Offline mode the page didn't load at all, or it loaded forever, or displayed an Unknown Error and Failed to fetch
• unable to wipe the application (SW) cache from Application tab
• registered service worker magically disappeared from SW tab under Application tab, when refreshed in offline mode

So, all that happened in my app, and when I was trying to figure out what I did wrong, I tried your demo app. That's where I found the only difference. Which is the / before the file name in the register call.
So with this registration code: navigator.serviceWorker.register('/service-worker.js');, it behaves properly.
Try removing the slash, wipe the cache, and try offline mode. Try online mode and breakpoints. You may not run into all the problems I ran into, because I experienced all of them only like 70-80% of the time.

Second bug:
This one I am only 50% sure about (I should verify). After I fixed the / it stopped giving me unintelligible errors, and just outright failed to register. Why? Apparently, because it had previously cached the service-worker.js file into browser cache, and the registration call, when fetching the service worker, failed if the file was served from browser cache.
That probably isn't the desired behavior is it? If it is, it should give a more explanatory error.
The issue got fixed when I added no cache headers to my service-worker.js API handler and wiped the cache.

[jeffposnick]

Hello @vjancik—Apologies that this hadn't been responded to previously.

As you point out, many of the issues you relate in this bug relate to using the Chrome DevTools while debugging a service worker implementation, in this case a service worker generated by sw-precache. I'm trying to narrow down whether there's anything actionable on the sw-precache front here, separate from the issues you had with DevTools.

Registering a service worker using a relative URL should not, in and of itself, introduce the issues that you described. The basic demo for sw-precache uses a relative URL, for instance: https://github.com/GoogleChrome/sw-precache/blob/master/demo/app/js/service-worker-registration.js#L29

I tried running that demo locally, changing to an absolute URL, reloading, etc., and things worked fine without any of the issues you described.

This makes me wonder whether the issues you experienced were specific to the version of Chrome that you were using back in November. I've just tested with Chrome 56.

If you can reproduce any of the issues you describe with the DevTools in Chrome 56, starting from a fresh state, the best course of action would be to escalate to the Chrome team. We can do that via https://bugs.chromium.org/p/chromium/issues/entry and I'm happy to make sure that the issues get attention from the relevant engineers.