User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36

Steps to reproduce:

// service-worker.js

self.addEventListener('fetch', (event) => {
  const ctrl = new AbortController();

  ctrl.abort('doom');

  return event.respondWith(fetch(event.request, {
    signal: ctrl.signal,
  }));
})

Actual results:

The fetch handler throws that event.respondWith() received an Error instance instead of a Response instance. A network error is triggered and the request is marked in DevTools Network panel as 'failed'.

Expected results:

It should behave exactly as if the client had aborted the request itself: The request should be cancelled with reason 'doom', and DevTools Network panel should mark the request's status as 'cancelled'.

As is, there is no way to properly cancel a request from a ServiceWorker. For example, if the request is to a protected resource and the client has no authentication. Marking the request "failed" due to a network error is misinformation—the ServiceWorker aborted the request, there was no problem with the network.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.