W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

removeEventListener with only one passed parameter...

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Mon, 9 Jun 2014 20:07:28 +0000
To: "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, "Boris Zbarsky (bzbarsky@mozilla.com)" <bzbarsky@mozilla.com>, Cameron McCormack <cmccormack@mozilla.com>, "'public-script-coord@w3.org'" <public-script-coord@w3.org>
Message-ID: <0917efbc761f4ae48d22527ce819e965@BLUPR03MB344.namprd03.prod.outlook.com>
Hey folks,

I was reviewing a site-compatibility issue with IE on the phone, and ran across what I think to be a Chrome implementation bug, but I wanted to post my findings in case I messed up the interpretation—it has to do with undefined handling in WebIDL I think.

The API is removeEventListener defined in DOM4 [1] as:

void removeEventListener(DOMString type, EventListener? callback, optional boolean capture = false);

The site-compatibility problem occurs because the site is [unknowingly?] calling this API with only one param:


and no exception is thrown. In IE and Firefox, this throws because 2 params are expected to this function. In Chrome, the call silently fails (no exception). Note that IE and Firefox do not throw when passing undefined explicitly: ob.removeEventListener(‘click’, undefined).

Per WebIDL AFAICT, this method would be invoked with the following values: (‘click’, <missing>, false), since the optional 3rd arg with a default gets substituted when no value is passed (and would also be substituted if undefined as a value were specifically passed). I’m pretty sure the nullable 2nd arg is not considered “optional” per the “optionality” determination in WebIDL. If it is, then undefined would type-convert to null, and Chrome’s behavior of not-throwing is right, but I can’t quite see how that would work.

Would love your clarification. Is this a Chrome bug or a spec bug?

[1] http://w3c.github.io/dom/#eventtarget

Received on Monday, 9 June 2014 20:08:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:21 UTC