events: improve argument handling, start passive

[benjamingr]

Hey, this PR fixes argument handling for cases like addEventListener('foo', undefined) which is allowed as well as add a whatwg WPT test that tests this.

Note the actual passive tests don't pass (because we don't deal with passive).

IIUC passive means "if event.preventDefault is called from within a passive listener - don't preventDefault". I will make a PR fixing this after #33613 lands.

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

[BridgeAR]

While this might be spec compliant it's not ideal to allow this. It'll hide potential bugs.

[benjamingr]

@BridgeAR I see your point and thank your for championing developer experience and (what I consider) good default behavior for passing invalid arguments.

I don't think it's our place to make this call if we ship EventTarget, we should strive to make our EventTarget as spec compliant as possible (like our URL) within reasonable limitations.

This PR is a prerequisite for running (and passing) the WPTs for events. If you feel strongly about diverging from the spec here - I am fine with making NodeEventTarget (our extensions) behave differently from the spec although I'd argue that's more confusing.

I feel people generally would expect an EventTarget to behave in Node the same way it does in browsers . The spec allows passing null (and undefined by idl conversions IIUC).

I think we are probably going to find more fundamental issues with EventTarget (like the error handling behavior, where I would particularly value your opinion and feedback) - and we should probably pick our battles here if/when we want to diverge from the spec or ask for it to be amended.

[benjamingr]

@BridgeAR I checked with Anne on IRC, it sounds like emitting a warning is allowed from a spec point of view. Would that address your concern?

(for reference here is my conversation with Anne)

<benjamingr>Just checking, how bad would it be for Node to behave differently from `EventTarget` regarding `addEventListener('eventName', null)`? https://github.com/nodejs/node/pull/33637#pullrequestreview-420889677
3:27 PM <annevk> benjamingr: do you have a developer console equivalent?
3:28 PM <benjamingr> Benjamin Gruenbaum annevk: We have `stdout` (and stderr for warnings) :] 
3:28 PM <annevk> I'd use that; I think as Domenic mentioned elsewhere, if you're not going for full compatibility, it'll just be confusing
3:29 PM <benjamingr> Use that to do what? Emit a warning for example? 
3:29 PM <annevk> benjamingr__: yes
3:30 PM <benjamingr> I  generally agree with Domenic (and that PoV). Would Node.js writing a warning to `stderr` for passing `undefined` or `null` as a second argument be allowed from a spec point of view?
3:31 PM <annevk> benjamingr__: yeah, console is UI territory
3:31 PM <benjamingr__> Ok great, thanks again. I'll go ahead and suggest that in the issue and see if it helps.

[benjamingr]

@BridgeAR I've updated the code to emit a warning on incorrect usage, PTAL.

[jasnell]

I don't like it for the same reasons as @BridgeAR but... Ok

[BridgeAR]

@benjamingr thanks for adding the warning. I agree that there might be more issues that we find and we should probably open a tracking issue for things where we believe the user experience is not ideal. That way it would be easier to determine what we could/should bring up to discuss to improve in the spec itself.

[benjamingr]

@jasnell this was out of sync, rebased this and the others

[nodejs-github-bot]

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

[ronag]

Any chance we could use a different submodule prefix for EventTarget? I always get confused whether these commits are regarding event emitter or event target... especially since the description often can at least partly apply to either.

[jasnell]

Closing in favor of #34015 (which combines this and other eventtarget PRs into a single to make landing easier