So I'll keep this succinct: When trying to install, my service worker fails. This is all of my code in sw.js:

var cacheName = 'randomstring';
var filesToCache = [ '/' ];

self.addEventListener('install', function (e) {
    console.log('[ServiceWorker] Install');
    e.waitUntil(
        caches.open(cacheName)
            .then(function (cache) {
                console.log('[ServiceWorker] About to fail');
                return cache.addAll(filesToCache);
            })
    );
});

I get an exception because cache is undefined (on the cache.addAll bit).

Not really sure why this is the case?

I've used service workers before and never encountered this issue. This is my first time using a service worker with an ASP.Net back-end though, so not sure if that's the problem?

asked Jun 7, 2017 at 4:09

Maverick's user avatar

0

So, I figured this out. I was going to vote to close the question, but I figured I'd leave it here as I saw some other people with this issue who didn't know how to resolve it. Even though it's super-stupid :) (or more accurately, I am).

So I was running the website via the "Play" button, aka "Start Debugging", which, in Visual Studio 2017, launches a special Chrome window, in which the above error will be thrown.

To work around the issue, I can (or you can, internet traveller of the future) simply start without debugging, host the website in IIS, etc.

EDIT: If there's a better workaround where I can use the service worker in debug mode, please suggest it and I'll mark that as the answer. For my specific problem though, the above workaround is fine :).

answered Jun 7, 2017 at 4:47

Maverick's user avatar

Maverick

4,4895 gold badges38 silver badges49 bronze badges

2 Comments

This issue is pretty old at this point, but if anyone else is running in to this, the root cause is actually an odd Chrome bug (bugs.chromium.org/p/chromium/issues/detail?id=1054541) where if the --user-data-dir path set when Chrome is launched is longer than 133 characters, the Cache API stops working. Visual Studio sets this to a custom (and long-ish) path to give you a fresh instance of Chrome for debugging (e.g. without extra extensions, clean cache, etc.).

The workaround that @Ceffis mentions below (using the "Browse With..." option in VS) should work well until the Chromium bug is fixed.

Encountered the same problem and found some other ways.

VS recognises "chrome.exe" while debugging and adds some parameters, that´s why service workers won´t working.

There is an option Debug => Option => Debugging => General => Enable javascript debugging for asp.net (Chrome, Edge and FireFox). If you don´t want to use js debugging in vs - like me because i use chrome for js debugging - just deactivate this option and service workers will work. VS Enable JS Debugging in Chrome

Alternatively you can add chrome as a new "browser" and switch the browser for debugging. Because vs recognise "chrome.exe" make a symlink via administative commandline "mklink chromedirect.exe chrome.exe" and add it as new browser in visual studio.

This can be done under the "Play" context menu => Browse with. VS Play Context Menu

Just add chromedirect.exe without any arguments and a friendly name like "Google Chrome Direct". After that you can switch to the browsers and select if you want VS JS Debugging or not.

Chris Love's user avatar

Chris Love

3,9031 gold badge22 silver badges17 bronze badges

answered Sep 9, 2017 at 8:55

Ceffis's user avatar

Ceffis

511 silver badge4 bronze badges

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.