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

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?

Start by reviewing the Fetch Standard's request client or window association and the discussion in this issue about destroyed windows and stopped documents. The issue is done when the specification has a decided, explicit behavior for closed windows and for fetch(event.request) after the source window is stopped.