Only specific APIs should skip the fetch event when called within a service worker

[mvano]

Currently it is not clear whether resource fetches for notifications (e.g. icons) shown from a service worker should trigger the service worker onfetch handler. As a use case it makes sense to enable offlining these resources.

My understanding is that fetches initiated directly from a service worker are not passed through the service worker onfetch handler, which seems reasonable. However, what about the fetches triggered indirectly by actions initiated in the service worker, like showing a notification?

CC @annevk @jakearchibald @beverloo @slightlyoff

[beverloo]

+1, notification resources should be cacheable by a Service Worker regardless where a notification was shown from. Today this is a failure case for people using push on flaky connections, in a future having a job scheduler/timers there is no guarantee that the device will be online at all when a notification is to be shown.

[annevk]

How many APIs in a service worker can cause a fetch?

1. fetch() (we cannot let that be captured by the same service worker)
2. openWindow() (is captured, though not necessarily by the same service worker, depends on the URL)
3. showNotification() (currently not captured, despite being able to fetch multiple resources that should probably work offline)
4. ?

[annevk]

@jungkees @wanderview @jakearchibald you might want to discuss this at the SW F2F?

[annevk]

@mvano it might be better to file this at https://github.com/slightlyoff/ServiceWorker/issues/new perhaps? Or at least track it in both places.

[wanderview]

I don't see anything in the notifications API about setting the skip-service-worker flag:

https://notifications.spec.whatwg.org/#fetch-steps

So I think per spec this should be intercepted. This isn't all that different from Client.navigate() which might also trigger an onFetch.

So I think it should be intercepted. I'm not sure what behavior is currently implemented, though. It would be nice to have a test case.

[wanderview]

Actually, I take that back. Something like foreign fetch would allow these to be intercepted. Currently I don't think the notification image is loaded in a controlled Client, so its not intercepted.

[wanderview]

An alternative here would be to let the Notification API accept Response objects instead of URLs. Then the SW push event handler could specify resources it already has offlined without a separate fetch event.

[annevk]

Foreign fetch only works across origins. Same-origin is not intercepted since the request client is the service worker itself.

[wanderview]

@annevk What is the "origin" of the notification popup? Is it even defined as a window or Client? AFAICT these requests made from within the browser without a window defining a source origin. No?

[annevk]

The origin of a notification is the origin of the global it was created in. But I was talking about the notification's resources, not the notification itself.

[wanderview]

@annevk The spec seems a bit vague right now. Notification API says to "fetch notification’s icon URL". It links, however, to a spec text in fetch that depends on having a request:

https://fetch.spec.whatwg.org/#concept-fetch

How does the conversion from URL to request occur here?

[annevk]

@wanderview that seems like something that should be fixed, but in principle a notification is no different from <img>.

[wanderview]

Well, it matters when I'm trying to figure out what the Client should be to determine if its controlled or not.