Re: [w3c/ServiceWorker] Support `close()` method in ServiceWorkerGlobalScope (Issue #1696)

> A service worker can be processing many different ExtendableEvents at the same time, and without manual bookkeeping there isn't really a way for a service worker script to know what events are in progress.

I'd go further than this.  Because of the involvement of multiple threads and potentially multiple processes, the ServiceWorker agent thread inherently is not in a position to be able to reason about whether it's appropriate to self-terminate even with bookkeeping.  [Everything leading up to the task queued by step 6 of fire a functional event](https://w3c.github.io/ServiceWorker/#fire-functional-event-algorithm) is outside of its awareness.

This would be further exacerbated by how close() is currently specified.  [Close a worker](https://html.spec.whatwg.org/multipage/workers.html#close-a-worker) is specified to discard outstanding tasks and sets the [closing flag](https://html.spec.whatwg.org/multipage/workers.html#dom-workerglobalscope-closing) which [discards any future tasks](https://html.spec.whatwg.org/multipage/workers.html#worker-event-loop:dom-workerglobalscope-closing).  The worst part is that calling close() does not immediately abort execution of JS and potentially allows the worker to continue performing observable actions.  (However, we have made improvements here, like BroadcastChannel's [eligible for messaging check](https://html.spec.whatwg.org/multipage/web-messaging.html#eligible-for-messaging) treats a worker in the zombie post-close-still-running-JS state as not eligible for messaging which [is checked as the first step of postMessage()](https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts:eligible-for-messaging) so the worker can no longer be observable over BroadcastChannel.)

That said, even if close() did immediately throw an uncatchable error after it set the closing flag, I still don't think it would be appropriate to expose on ServiceWorkers.

#### Use Cases

> A developer is writing tests and wants to immediately terminate the service worker (https://github.com/w3c/webextensions/issues/311#issuecomment-1764675350).

This is an important use-case, but it seems like it is better addressed by adding a [WebDriver extension command](https://w3c.github.io/webdriver/#extensions-0) which could be used by sites for testing, and then also exposed to [testdriver.js](https://web-platform-tests.org/writing-tests/testdriver.html) for use in any Web Platform Tests.

For example, I see that [testdriver.js documents FedCM-specific capabilities](https://web-platform-tests.org/writing-tests/testdriver.html#federated-credential-management) which seems to be [documented as a WebDriver extension in the FedCM CG draft report](https://fedidcg.github.io/FedCM/#automation).

> In general, a service worker no longer has any work to perform and wishes to free up resources.

It would be good to understand how the existing functional event mechanism and the ability of content to help out garbage collection are believed to be insufficient here.  Especially as, to reiterate the top point, in general a ServiceWorker does not have the ability to reason about future events that might occur or what the cost to restarting the ServiceWorker would be.

> A developer is handling sensitive data in the service worker (e.g a password manager). When the user asks the password manager to lock, immediately terminating the service worker would provide some additional certainty that any data in memory can be freed (https://github.com/w3c/webextensions/issues/311#issuecomment-1326648334).

I'm unclear if there's an assumption here that freed memory will not be available to an attacker with the ability to arbitrarily read the contents of the process' address space, but it seems like https://github.com/w3c/ServiceWorker/issues/1529 could provide more confidence about this anyways.  (Although there's still a bunch of browser latitude in how to implement terminate(), it's strictly stronger than close().)

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

Message ID: <w3c/ServiceWorker/issues/1696/1787712130@github.com>