what should fetch() do if request's window has been destroyed or stopped?

[wanderview]

The fetch spec currently associates the current client or window with a request object. This is important for allowing fetch(event.request) in service workers to work when the request requires mixed content or client certificate dialogs. These requests need UX interaction to work properly.

There is a race, however. Between the time the request is created and when the fetch() uses the window property, the original window can:

1. Be closed or otherwise destroyed.
2. Have its stop button pressed.

It seems the spec should handle (1) by checking if the window is closed before permitting mixed content and client certificates.

For (2), I have more questions...

In gecko we treat pressing the stop button as cancelling all document related network requests. By associating the window with the request, we could also cancel fetch(event.request) when the original window is stopped (or closed). Should we?

On the one hand, it seems to reflect the wishes of the user. On the other hand, the service worker may want to do event.waitUntil(cache.add(event.request)) with the intention of caching it in the background.

Thoughts?

[annevk]

This is basically https://www.w3.org/Bugs/Public/show_bug.cgi?id=23878. Once a window goes away the fetch group needs to be terminated, which terminates all the fetches.

Not sure what the stop UI should do. Does it typically prevent any further fetches? As a user I'm never quite sure what that button does.

[wanderview]

But should it terminate fetch's made with a fetch event handler in a service worker with fetch(evt.request)?

[wanderview]

To clarify, if an "outer fetch()" is intercepted by a SW which then makes an "inner fetch()":

1. Clearly the outer fetch() should be canceled when the window is closed/stopped
2. But should the inner fetch() be part of that same fetch group and canceled?
3. It seems (2) is only possible if the inner fetch() uses event.request

[annevk]

• So yes, the race condition does exist. Not sure what to do about it.
• Perhaps the service worker ought to be notified when a fetch is terminated. This is something it cannot currently act upon.
• Perhaps when you have a "passthrough" fetch of sorts they should become linked, and terminate one terminates the other?

[annevk]

@jakearchibald any thoughts on this now we have abort handling?

[Mouvedia]

I hope they aligned AbortController#abort with XMLHttpRequest#abort.
I was really surprised when I didn't find any tests regarding this issue in that directory.

[bradisbell]

Similar to the user pressing the stop button, aborted media requests seem to have inconsistent behavior in browsers today.

Suppose you have an Audio object pointed at https://example.com/some-live-stream. The live stream is a live HTTP progressive stream that has indefinite length. Now, suppose you have a service worker:

self.addEventListener('fetch', (e) => {
  e.respondWith(fetch(e.request));
});

Now, kill the audio src:

audio.src = '';

On Chrome, the audio stream request is cancelled, which is what I would expect. On Safari, the request keeps on going.

[paralin]

w3c/ServiceWorker#1544 (comment)

It seems that ServiceWorker does not abort the request.signal when a tab is closed today.