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

I would prefer if I could depend on abort signals being delivered. It seems odd if the signal offers it, I say I want it, and some other unrelated code shoots the messenger and prevents it from ever arriving.

This makes sense in a DOM tree where one node can say "OK I've handled this, it's done, no one else needs to handle it again". But responses to an abort are independent. Stopping an abort is like saying "OK I've stopped my piece, no one else needs to stop anything else, go ahead and leak all those resources". When would you ever need to legitimately cancel an abort partway through? The abort is the cancelation. You shouldn't be able to cancel cancelation.

What about a new property on `Event`? `bubbles` can prevent bubbling. `cancelable` can shut off `preventDefault()`. What if `unstoppable` could shut off `stop*Propagation()`?

```js
signal.addEventListener('abort', event => {
  // Does nothing and raises a warning,
  // just like preventDefault() when cancelable === false
  event.stopImmediatePropagation()
})
const event = new Event('abort', { unstoppable: true })
signal.dispatchEvent(event)
```

This is in line with existing functionality. It keeps the existing dispatch mechanism. It keeps the current default of events being stoppable, and adds an option to control it for events that need it.

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

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