We Keep Coding

service worker doesn't skip waiting state

I'm still doing experiments in order to master service workers, and I'm facing a problem, probably because of my lack of expertise in JavaScript and service workers.
The problem happens when I want the new service worker to skipWaiting() using postMessage(). If I show a popup with a button and I bind a call to postMessage() there, everything works. If I call postMessage() directly, it doesn't work. It's a race condition because SOMETIMES it works, but I can't identify the race condition.
BTW, the postMessage() call WORKS, the service worker is logging what it should when getting the message:
// Listen to messages from clients.
self.addEventListener('message', event => {
switch(event.data) {
case 'skipWaiting': self.skipWaiting(); console.log('I skipped waiting... EXTRA');
break;
}
});
Here is the code. The important bit is on the if (registration.waiting) conditional. The uncommented code works, the commented one doesn't:
// Register service worker.
if ('serviceWorker' in navigator) {
// Helpers to show and hide the update toast.
let hideUpdateToast = () => {
document.getElementById('update_available').style.visibility = 'hidden';
};
let showUpdateToast = (serviceworker) => {
document.getElementById('update_available').style.visibility = 'visible';
document.getElementById('force_install').onclick = () => {
serviceworker.postMessage('skipWaiting');
hideUpdateToast();
};
document.getElementById('close').onclick = () => hideUpdateToast();
};
window.addEventListener('load', () => {
let refreshing = false;
navigator.serviceWorker.addEventListener('controllerchange', () => {
if (refreshing) return;
refreshing = true;
window.location.reload();
});
navigator.serviceWorker.register('/sw.js').then(registration => {
// A new service worker has been fetched, watch for state changes.
//
// This event is fired EVERY TIME a service worker is fetched and
// succesfully parsed and goes into 'installing' state. This
// happens, too, the very first time the page is visited, the very
// first time a service worker is fetched for this page, when the
// page doesn't have a controller, but in that case there's no new
// version available and the notification must not appear.
//
// So, if the page doesn't have a controller, no notification shown.
registration.addEventListener('updatefound', () => {
// return; // FIXME
registration.installing.onstatechange = function () { // No arrow function because 'this' is needed.
if (this.state == 'installed') {
if (!navigator.serviceWorker.controller) {
console.log('First install for this service worker.');
} else {
console.log('New service worker is ready to activate.');
showUpdateToast(this);
}
}
};
});
// If a service worker is in 'waiting' state, then maybe the user
// dismissed the notification when the service worker was in the
// 'installing' state or maybe the 'updatefound' event was fired
// before it could be listened, or something like that. Anyway, in
// that case the notification has to be shown again.
//
if (registration.waiting) {
console.log('New service worker is waiting.');
// showUpdateToast(registration.waiting);
// The above works, but this DOESN'T WORK.
registration.waiting.postMessage('skipWaiting');
}
}).catch(error => {
console.log('Service worker registration failed!');
console.log(error);
});
});
}
Why does the indirect call using a button onclick event works, but calling postMessage() doesn't?
I'm absolutely at a loss and I bet the answer is simple and I'm just too blind to see it.
Thanks a lot in advance.

Looks like a bug in Chromium or WebKit, because this code works all the time in Firefox but fails in Chrome and Edge most of the time.
I've reported that bug to Chromium, let's see if it is a bug or my code is weird. I've managed to build the smallest code possible that still reproduces the issue, it's quite small and it can be found on the bug report.
The report can be found here.
Sorry for the noise, I'll keep investigating the issue but no matter how I tried, the code still fails from time to time, I can't spot the race condition on my code.

Service Worker "fetch" event for requesting the root path never fires

I am trying to set up my Service Worker so that it intercepts the request for the home page (ie the home page, like www.mywebsite.com/), which would eventually allow me to return a cached template instead. My code looks like this so far:
main.js:
navigator.serviceWorker.register('/sw.js')
sw.js:
self.addEventListener('fetch', function(event) {
console.log(event.request.url)
/**
* only ever detects requests for resources but never the route itself..
*
* logged:
* https://www.mywebsite.com/main.js
* https://www.mywebsite.com/myimage.png
*
* not logged:
* https://www.mywebsite.com/
*/
})
I'm pretty sure the service worker is getting set up correctly, as I am indeed detecting events being fired for requests for resources (like /main.js or /myimage.png). However, the problem is that only the resources' events ever get fired, even though I'd like that event for requesting the route itself (/) to be fired. Am I missing anything, or should I be listening for a different event?
Thanks

I discovered that the request for the root path was in fact getting intercepted. The reason I never noticed this is because the request happens before the page is loaded (ie before there's even a console to log to). If I turn on the Preserve log feature in Chrome DevTools, I will notice the logs for the root path requests as I should.

You can chain .then() to. .register() call then check location.href to determine the page at which the ServiceWorker has been registered
navigator.serviceWorker.register("sw.js")
.then(function(reg) {
if (location.href === "https://www.mywebsite.com/") {
// do stuff
console.log(location.href, reg.scope);
}
})
.catch(function(err) {
console.error(err);
});

I just figured this out, with help from https://livebook.manning.com/book/progressive-web-apps/chapter-4/27.
Here's a short version of my service worker:
const cacheName = "Cache_v1";
const urlsToCache = [
"Offline.html"
// styles, images and scripts
];
self.addEventListener('install', (e) =>
{
e.waitUntil(
caches.open(cacheName).then((cache) =>
{
return cache.addAll(urlsToCache);
})
);
});
self.addEventListener('fetch', (e) =>
{
if (e.request.url == "https://<DOMAIN_NAME>/")
{
console.log("root");
e.respondWith(
fetch("offline.html")
);
}
}

Activating a ServiceWorker earlier?

Is it possible to tell the browser to start the ServiceWorker activation and installation phases earlier?
When I look at our performance in Chrome, which you can see below, the worker is loaded within the first 1.5s, but the activation takes place not before 3.3s! Is there a way to tell the browser to do the ServiceWorker installing and activation as soon as possible?
Here is my ServiceWorker code:
self.addEventListener('install', (event) => {
// Bypass the waiting lifecycle stage,
// Just in case there's an older version of this SW registration.
event.waitUntil(self.skipWaiting());
});
self.addEventListener('activate', (event) => {
// Take control of all pages under this SW's scope immediately,
// Instead of waiting for reload/navigation.
event.waitUntil(self.clients.claim());
});

To check if ServiceWorker is in waiting state

I am trying to understand the Service Worker API, and I know the bits and parts about registering a Service Worker.
As stated in the API doc, if a service worker update is found, the service worker is registered and added to the queue. This SW takes over a page if and only if, the page is closed and opened again.That is, A window is closed and reopened again.
Now, this has a few downfalls:
The user might be seeing a previous version that might have a very serious grammatical mistake, or whatever.
The user needs to be somehow notified that the content has changed and that a referesh would do it.
I know how to tell the SW.js to skipWaiting() and take over. I also know how to send a message to the SW.js telling it that the user wants a automatic refresh.
However, what I do not know is how to know whether a new SW is actually in a waiting state.
I have used this:
navigator.serviceWorker.ready.then((a) => {
console.log("Response, ", a);
if (a.waiting !== null && a.waiting.state === "installed") {
console.log("okay");
}
});
However, it usually returns the waiting state as null.(Possibly because the SW is still installing when the request is fired.)
How can I know on the client page that a waiting service worker is available?

Here's some code that will detect and allow you to handle various states whenever there's a new or updated service worker registration.
Please note that the log message assumes that skipWaiting() is not being called during the service worker's installation; if it is being called, then instead of having to close all tabs to get the new service worker to activate, it will just activate automatically.
if ('serviceWorker' in navigator) {
window.addEventListener('load', async function() {
const registration = await navigator.serviceWorker.register('/service-worker.js');
if (registration.waiting && registration.active) {
// The page has been loaded when there's already a waiting and active SW.
// This would happen if skipWaiting() isn't being called, and there are
// still old tabs open.
console.log('Please close all tabs to get updates.');
} else {
// updatefound is also fired for the very first install. ¯\_(ツ)_/¯
registration.addEventListener('updatefound', () => {
registration.installing.addEventListener('statechange', () => {
if (event.target.state === 'installed') {
if (registration.active) {
// If there's already an active SW, and skipWaiting() is not
// called in the SW, then the user needs to close all their
// tabs before they'll get updates.
console.log('Please close all tabs to get updates.');
} else {
// Otherwise, this newly installed SW will soon become the
// active SW. Rather than explicitly wait for that to happen,
// just show the initial "content is cached" message.
console.log('Content is cached for the first time!');
}
}
});
});
}
});
}

ServiceWorker: No FetchEvent for javascript triggered request?

I am using Chrome stable 46.
I have a very basic site. One button.onclick that fetch('a') and one <a> tag that opens b. Both urls a and b do not exist, I intend to catch them in the service worker and just return a new Response().
If I click on the button which fetches a, the service worker is not involved and I get a 404 error.
But if I click on the link that goes to b, the service worker onfetches and returns the response.
Question: Why is the service worker not getting any FetchEvent for the fetch('a') request?
See the files below
HTML
<html>
<body>
<p><button onclick="fetch('a');">fetch a</button></p>
<p>go to b</p>
<script src="js.js" defer></script>
</body>
</html>
js.js
navigator.serviceWorker.register('sw.js');
sw.js
self.onfetch = function(event) {
var request = event.request;
event.respondWith(
caches.match(request).then(function(response) {
return new Response('here is your onfetch response');
})
);
};

The service worker's fetch event handler isn't being called the first time you load the page because the service worker hasn't yet "claimed" the page, meaning it's not under the service worker's control. By default, the first time you visit a site that registers a service worker, the service worker's install (and potentially activate) event handlers will run, but fetch won't get triggered until the service worker takes control. That happens the next time you navigate to a page under the service worker's scope, or if you reload the current page.
You can override this default behavior and have the service worker take control during the initial navigation by calling self.clients.claim() inside your activate event handler.
I also want to point out that the fetch event handler in your sample has some issues—there's no reason to call caches.match(request) if you're always planning on returning a new Response object. More importantly, you need to do some sort of check of the event.request.url value and only return the new Response if it matches one of your "special" URLs, which in your case is a and b. The way things are implemented now, your fetch handler will return the dummy Response unconditionally, even if it's a subsequent request for your main page (index.html). That's presumably not what you want.
I put a gist together that modifies your service worker code to accomplish what I believe you're attempting. You can try out a live version thanks to RawGit. For posterity, here's the modified service worker code:
self.addEventListener('install', event => {
// Bypass the waiting lifecycle stage,
// just in case there's an older version of this SW registration.
event.waitUntil(self.skipWaiting());
});
self.addEventListener('activate', event => {
// Take control of all pages under this SW's scope immediately,
// instead of waiting for reload/navigation.
event.waitUntil(self.clients.claim());
});
self.addEventListener('fetch', event => {
// In a real app, you'd use a more sophisticated URL check.
if (event.request.url.match(/a|b$/)) {
event.respondWith(new Response('here is your onfetch response'));
}
});