Benjamin Gruenbaum

I would add the note about isTrusted [here](https://dom.spec.whatwg.org/#dom-event-istrusted) and the note about passive [here](https://dom.spec.whatwg.org/#ref-for-event-listener-passive%E2%91%A0) or [here](https://dom.spec.whatwg.org/#event-listener-passive) because that's where it would have helped me. Thanks again, I tried doing a...

@jakearchibald in Node.js yes - but: - In spec-land this would probably be just explained (like other things in the GC section of the spec). - In browsers this would...

> Just to clarify, the resource only stays in memory until signal is GC'd, at which point it's all collected. The issue is that sometimes you have a (very) long...

@jakearchibald sure, that's a good question/point. Here are two quick examples: ---- With timers (since they're the simplest API): ```js // before async function setTimeout(ms, { signal } = {})...

> it's using GC observation to help other things get GCed, not to do important program logic. So I'm not too worried there. That's a good point. > Another angle...

> (I removed a || || from the code above, sorry if that's part of an upcoming proposal I'm not aware of) No no that was just a typo ^^...

@jakearchibald this is pretty similar to what James had in mind in https://github.com/nodejs/node/issues/37220#issuecomment-773370510 @getify what do you think? Would Jake's idea version (returning a promise) address your use case? @jasnell...

> If it's true that this is a server-focused problem and doesn't matter for browsers, and that solving it requires such a large and complicated bunch of machinery, then I...

Or, you know - use native promises instead. They are available, fast and easy to debug in every version of Node.js you support and are superior to Q in every...

Thanks, please keep me updated.