Repository navigation
Userland AbortSignal #1195
Description
Splitting this from #1016.
Writing a robust userland AbortSignal consumer is tricky. In particular you might not get your event listener due to someone else listening calling stopImmediatePropagation().
Possible solutions:
- We invent a new way of dispatching that disallows preventing
stopImmediatePropagation(). (@smaug---- is not a fan of this as per the other thread.) - The consumer uses
AbortSignal.any()to get a copy without other event listeners and registers their event listener there. - We define userland "abort algorithms" somehow.
Reacted by Benjamin Gruenbaum
Activity
benjamingr commentedon May 8, 2023
Thanks for opening,
Using
AbortSignal.any([signal])just to use the fact it exposes an underlying different mechanism in the DOM seems like not a great design. It's similar to making a dummy hangingfetchrequest and.catching it to know cancellation happened.I'm trying to get around having another way to dispatch things, @smaug---- can you elaborate what specifically about not being able to prevent other listeners from running bothers you?
smaug---- commentedon May 8, 2023
It would be odd to have special event dispatch mechanism just for AbortSignal. We've had the consistent way for decades - stop*Propagation works everywhere. Why it should behave differently here?
Also, I'm having trouble to see the issue with using AbortSignal.any.
Btw, is there a concrete issue here, or is this just some theoretical one?
benjamingr commentedon May 9, 2023
There is a real issue, userland uses
addEventListener("abort"for resource cleanup and other listeners being able to prevent that is unfortunate.At the moment AbortSignal already has a second dispatch mechanism but it's only exposed to the dom internally and
AbortSignal.anyadds a third.benjamingr commentedon May 17, 2023
Any update on this? I feel like we're adding a third way to do something (with any) - and the first two are problematic and there is no safe userland way to use AbortSignal until this is resolved (though to be fair in practice we haven't received complaints).
annevk commentedon May 17, 2023
Well,
AbortSignal.any()does give userland a way. And by-and-large folks are satisfied with theAbortSignal.any()design so I'm going to land that change, especially now it's getting multiple implementations.I'll keep this open to see if many other people are running into this and if we need to make further improvements.
benjamingr commentedon May 17, 2023
So we should be recommending people always do
AbortSignal.any([signal]).addEventListener("abort"when adding abort listeners?annevk commentedon May 17, 2023
Maybe? That's certainly the only way to do it if you run into this problem. As I said above, if enough people run into this problem we should consider solving it better.
benjamingr commentedon May 20, 2023
@annevk should we maybe add a note in the specification suggesting it as a safe way to ensure a listener runs?
benjamingr commentedon Jul 4, 2023
We (node) shipped (are shipping) our own helper to add a listener without the stopImmediatePropagation issue as since Node is a server runtime a resource leak is potentially catastrophic for us. We'll hopefully also add a resource argument for it so it holds the listener weakly on the resource but that's planned for later.
I honestly wish I would have listened better to library authors when they were complaining about this before adding it to Node APIs but I think this is mostly blocked in the WHATWG side on someone doing the spec work to fix this API wise.
bakkot commentedon Dec 24, 2025
This would be fixed by #1425.