- From: anonghuser <notifications@github.com>
- Date: Sat, 11 Jul 2026 13:43:32 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/578/4948692819@github.com>
anonghuser left a comment (w3c/ServiceWorker#578) Even though this was closed, I'll still add my use-case for people that wonder why someone might want this: I want to be able to create a service worker for some site in my tampermonkey userscripts. To alleviate your security concerns, it does not need to be as permanent as current service workers are - it should only affect the documents/tabs that explicitly register it, not all other tabs of the target domain. As such it is fine that it will never capture the initial load/reload of documents, direct downloads or image/video/audio media opened in a tab of its own. Sharing a single service worker across tabs would still be good to have when they both register the same blob or data url, so bonus points if the blob url can be kept alive as long as other tabs still refer to it even after the tab that created it was closed. But if that's too complicated data urls would suffice. For the moment this use-case can be vaguely approximated by monkeypatching fetch and xhr and giving up on intercepting media requests, which often defeats the purpose of wanting the simple single universal request interception API of service workers, or by having userscript extensions like tampermonkey expose the extension fetch api in some form which is very clunky, much harder to write for and ultimately often implemented as not flexible/dynamic enough again because of "security". -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/578#issuecomment-4948692819 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/578/4948692819@github.com>
Received on Saturday, 11 July 2026 20:43:36 UTC