Re: [ServiceWorker] Workers & SharedWorkers within ServiceWorkers (#678)

@jungkees:

> To clarify, we're counting the case where no tabs are alive when a sync event signals to do the background jobs, right?

Correct, the backgroundsync service worker case could trigger the email sync logic when there are no browser windows showing an document from the email app.

It is good to know that the document has options via `navigator.serviceWorker.register` and its `registration` return value. Although, I think the longer term hope is that the service worker(s) used by the app can be registered via the webapp manifest, since we really want the fetch service worker to be able to handle all requests, streamline the service worker bootstrapping. In that scenario, I can see where we would code the HTML/JS for the web pages to not explicitly reference register a service worker, and not explicitly manipulate a `registration` return value.

We likely should not get into that bootstrapping in this bug, just mentioning it to give more signal to this bug, where I believe just allowing service workers to participate in the shared worker reference refcounting should be enough for the email use case (with the knowledge that `waitUntil(p)` needs to be used by the service worker to keep it alive long enough to keep the shared worker alive, as you mentioned).

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/678#issuecomment-94046451