Re: [whatwg/dom] Userland AbortSignal (Issue #1195)

Here's an example of the effect. The user tries to stop everything but only one operation stops.

https://bojavou.github.io/canceled-abort/

![example](https://github.com/whatwg/dom/assets/134245276/5c87cc52-ea2b-4efb-9f54-c96309855234)

```js
function aborted (event) {
  // The rest of my app doesn't need this, stop the event for efficiency
  event.stopImmediatePropagation()
  reject(signal.reason)
}
```

The developer thinks stopping the event is good for efficiency. That's reasonable and has been legitimate and beneficial since events began. But it's no longer true for an abort. Stopping an abort breaks user expectations.

Once delivered, the abort signal cannot be triggered again, and there's no way to provide a new signal to the ongoing operations, so this breaks cancelation nonrecoverably. User intuition is cancelation should work when requested. Developer intuition is an abort signal should deliver what it offers. This is counterintuitive for everyone involved.

Since there's no legitimate reason to stop an abort, and it has this highly visible and frustrating-to-the-user effect which the app can't recover from, I say it shouldn't even be possible. If `AbortSignal` becomes the standard for cancelation across the entire ecosystem, it shouldn't have this fragility built into it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1195#issuecomment-1616328603
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1195/1616328603@github.com>