This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23186 - EventListener argument of addEventListener and removeEventListener should not be nullable
Summary: EventListener argument of addEventListener and removeEventListener should not...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords: has-testcase
Depends on:
Blocks:
 
Reported: 2013-09-09 06:45 UTC by Masayuki Nakano
Modified: 2014-02-19 01:40 UTC (History)
6 users (show)

See Also:

Attachments

Description Masayuki Nakano 2013-09-09 06:45:28 UTC 
The definition table of arguments of addEventListener and removeEventListenr defines the EventListener as nullable ("✔").

However, the explanation documents: The listener parameter MUST be an object that implements the EventListener interface or a function.

Additionally, I have no idea the purpose of the argument nullable.

So, I think that they should be "✘".
Comment 1 Ms2ger 2013-09-09 07:50:08 UTC 
No, that would imply throwing an exception when null is passed. No browser does that.
Comment 3 Masayuki Nakano 2013-09-10 09:58:07 UTC 
So, did you mean that it should be nullable but implementations must throw an error if null is passed?
Comment 4 Ms2ger 2013-09-10 10:09:48 UTC 
> No, that would imply throwing an exception when null is passed.
> No browser does that.
Comment 5 Gary Kacmarcik 2013-10-23 14:17:19 UTC 
Updated text in the ED to explicitly say:
"If non-null, the listener parameter MUST ..."

But I don't see the point of allowing this parameter to be non-null. Adding or removing a null eventlistener seems useless.
Comment 6 Boris Zbarsky 2013-12-04 02:17:29 UTC 
> But I don't see the point of allowing this parameter to be non-null.

The point would be if there is code on the web that does that and doesn't expect an exception.

Given that no UA throws on null here, I don't think the spec should require the throwing behavior, unless you have some sort of indication that it is in fact web-compatible.  Which I doubt it is, frankly.
Comment 7 Jonas Sicking (Not reading bugmail) 2013-12-04 02:33:26 UTC 
Another way to put it: Which browsers would be willing to go first with such a change?

I agree that the risk/reward ratio of changing existing implementations seem too low here.