Links
- Specs
- https://w3c.github.io/ServiceWorker/
Questions
Can I use DOMParser in service workers?
Doesn’t seem like it.
I tried on 2024-02-01 using Firefox’s about:debugging
, inspecting a running service worker, and trying to type “DOMParser
” at the console.
No luck.
This comment from annevk suggests it’s not accessible because DOM implementation aren’t thread-safe.
Can a service worker uninstall itself
Imagine that a service worker doesn’t work on some browser (like, it’s an old browser that doesn’t support some new web feature, or it’s just Safari on iOS). Can I write a service worker in a way that’ll catch unexpected errors and have it uninstall itself and prevent reinstallation of the same version?
Answer
Yes, a service worker can uninstall itself, though it’s better to say that it can “unregister” itself. You can run
registration.unregister();
inside a service worker to unregister it. It only takes affect after controlled clients are unloaded. See the unregister() section of the Service Workers spec.
Unanswered questions
That is, I haven’t looked up or tried to answer them yet.
- If a Service Worker calls fetch, does that fetch use the HTTP cache? Or is the HTTP cache now bypassed entirely (essentially removing the effect of the
Cache-Control
header)? - Will HTTP requests with
If-Not-Modified
still occur? -
Is it possible to look up some stateful information in a fetch handler without using a
respondWith
? I’ve heard that passthroughrespondWith
is “bad” (why?), but it seems like I need to use respondWith if I’m using asynchronous APIs like IndexedDB.-
One thing I could do is start immediately fetching stateful data from some IndexedDB during initialization of the service worker. Then, once initialized, some global (to the service worker)
var
that starts offnull
orundefined
could be updated with a value. This would only persist until the worker is killed. -
Another option might be to only add the fetch event listener once stateful data is loaded. However, will this actually work? Does a service worker allow attaching event handlers later in some asynchronous operation?
-
Third option, like the first, would be to have two versions of the fetch event handler, which is bound to some
var
. After stateful data is loaded, the initial event handler is swapped out with a second one.
-
web.dev
mentioned that Firefox doesn’t correctly handleRange
requests. Is this still true?- If a Service Worker passes through a
Range
request for some video, will it attempt to cache everything? Can it be interrupted? Typically Firefox will find a video supportsRange
headers and will only load parts of videos (more or less). - I’ve read the Service Workers can be killed essentially at any time if they’re using too much resources. How much is too much? How likely is this to occur?
-
When fetching from
self.caches
, if a request matches multiple caches, what’s the order of listing (if defined at all)? -
I know that correctly setting the
Vary
header becomes important once you start using service workers, as it affects cache request matching. What are the specifics of that? -
A service worker can make a controlled client navigate to another location.
Can it make a controlled client load some JavaScript if no JavaScript had yet been loaded?
For example, a static article without JS is loaded from cache. In the background, a new version of the article is fetched. Is there a good way a service worker can notify the user that they may want to refresh?
- How do hard refreshes (like Control+Shift+R) interact with service workers?
Miscellaneous
Installation fires but not activation
I noticed that the “install
” event was being triggered, but not the “activate
” event for a service worker I was developing.
Turns out that the “install
” event was failing.
I had a cache.addAll
, and one of the resources returned a 404, causing the promise to reject.
Because this promise was used by event.waitUntil
, the installation also failed.
BroadcastChannel for debugging
Just a tip: One way to debug service workers without switching to about:debugging
is to have the service worker use a BroadcastChannel
to send messages to other windows.
Server-Sent Events issue
Having a service worker handle server-sent event streams caused some issues where the event stream would be prematurely killed. See my server-sent events notes page for more explanation on that and how I worked around the issue.