23186 2013-09-09 06:45:28 +0000 EventListener argument of addEventListener and removeEventListener should not be nullable 2014-02-19 01:40:57 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED has-testcase P2 normal --- 1 masayuki travil bzbarsky garykac jonas mike Ms2ger www-dom public-webapps-bugzilla oldest_to_newest 93154 0 masayuki 2013-09-09 06:45:28 +0000 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 "✘". 93155 1 Ms2ger 2013-09-09 07:50:08 +0000 No, that would imply throwing an exception when null is passed. No browser does that. 93156 2 Ms2ger 2013-09-09 08:01:16 +0000 https://github.com/w3c/web-platform-tests/pull/322 93190 3 masayuki 2013-09-10 09:58:07 +0000 So, did you mean that it should be nullable but implementations must throw an error if null is passed? 93191 4 Ms2ger 2013-09-10 10:09:48 +0000 > No, that would imply throwing an exception when null is passed. > No browser does that. 95196 5 garykac 2013-10-23 14:17:19 +0000 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. 97098 6 bzbarsky 2013-12-04 02:17:29 +0000 > 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. 97099 7 jonas 2013-12-04 02:33:26 +0000 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.