events: support signal in EventTarget

[benjamingr]

Fixes: #36073

This is this feature whatwg/dom#911 I've implemented the spec I worked on in whatwg/dom#919 and ported the WPTs from web-platform-tests/wpt#26472

This is following implementations from Chrome and Firefox and positive signals regarding the spec. I am happy to put this behind an experimental warning if you think that's a good idea.

Ping @jasnell

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[benjamingr]

This is in order to fix an unrelated bug where we cache the next handler in our dispatchEvent and still call it. Added a test or this case below.

[benjamingr]

FWIW: we should really add support for "weak" event listeners that is:

signal[kAddWeakListener]('abort',()=>{this.removeEventListener(type,listener,options);});

That would not retain the event target only because the signal exists (since if no one cares about the event retaining it for abort is mostly meaningless). I think a good path forward is:

• Make our listener list accept WeakRefs to listeners
• Put said listener behind a WeakRef
• Make our dispatch unwrap WeakRefs when it finds them.

@addaleax@jasnell if you think that's reasonable I'm happy to do this (either here or in a new PR)

[addaleax]

I think that’s reasonable here, yes… it’s way more common to think that you need a weak listener than it is to actually need one, so I wouldn’t expose this as public API, but for internal usage this sounds good :)

[jasnell]

My only concern there would be the potential additional performance cost. If the dispatch only incurs that cost for weak handlers then I'm definitely +1

[benjamingr]

@jasnell great, I'll do that at a separate pull request then.

@addaleax there are discussions for other use cases for this e.g. creating linked signals whatwg/dom#920 - there is a good explanation here: #35990 (comment)

I think we're running into the same issue with AbortSignal multiple times: If the resource will no longer be aborted and we're "done" with it we need to make sure that retaining the signal does not retain the resource. With some resources (like http.request, streams in general and timers) this is a relatively easy problem since we know when abort will be meaningless but with addEventListener and other resources this is less clear cut (hence the advantage of a weak handler to not have to manage this).

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/34552/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/34560/

[benjamingr]

Can this get a review @jasnell@addaleax ?

[benjamingr]

Kind of embarrassing that all the browsers are going to have this feature before us 😅 Though I am happy to wait a few more days for the whatwg/dom PR to be merged if that's a concern.

[github-actions]

Landed in 4a741b8...ef8d0e9

[targos]

This pull request lands cleanly on v14.x-staging, but I think the EventTarget constructor is not exposed, so I don't know how if we should adapt the tests somehow or just don't land it.

[benjamingr]

@targos I think it's fine not to land given EventTarget is not exposed though it's also fine to land (no harm) in order to make backporting future stuff easier. As you noted the constructor is not exposed so there should not be any user impact.