Re: [w3c/ServiceWorker] The promises returned by skipWaiting() should have more consistent activation-waiting behavior and not call Activate() multiple times (#1015)

> If you call it a second time, Activate() will be invoked again, aborting on step 1 ("If registration’s waiting worker is null, abort these steps.") because the previous Activate() call will have transitioned the worker to be the registration's "active worker". The promise will then resolve immediately regardless of whether the SW has activated or not.

> "Handle Service Worker Client Unload" calling Activate() races against the SW calling skipWaiting() at the request of an uncontrolled client's postMessage.

Right. It seems they obviously need to be fixed. Your suggestion would be an option here, but let me clarify two things around the desired behavior and the race condition.

First, when called on a waiting worker, do we want `skipWaiting()` promise to not resolve until the Activate is complete? This seems like a special case comparing to other cases where `skipWaiting()` just resolves after setting the flag (and waiting for it to happen.) One usage I can think of with the current behavior is:

```
self.onmessage = e => {
  e.waitUntil(
    self.skipWaiting().then(() => {
      e.source.postMessage('Activated.');
    })
  );
};
```

But I think the client already has other ways to detect the registration has an active worker that can control it such as `navigator.serviceWorker.ready` and `registration.active.onstatechange`. I'm not sure if it has other compelling usages. Please let me know if you've encountered any.

That said, I think it'd give more consistent and expected behavior to devs if `skipWaiting()` would resolve early even in the case that the state is "installed". Activate, of course, continues in parallel.

Secondly, having reviewed the steps again, Activate (currently cannot-be-queued job) and Unregister (queued job) can race on registration's waiting worker, I suppose. As far as I remember, this was previously pointed out by @wanderview. Sorry about that. I was worrying about it possibly blocking the Register/Update jobs in the job queue while waiting until no client is using the registration. However, I think it was just my confusion. It seems we can create and queue the Activate job outside the waiting condition. I wonder @wanderview still thinks it'd be right decision to make Activate a job to be queued in the job queue. If that's the case, we will probably be able to take advantage of job aggregation as well.

/cc @jakearchibald 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1015#issuecomment-263249320