13433 2011-07-28 21:47:17 +0000 Event handler IDL attributes need [TreatNonCallableAsNull] 2011-10-16 05:46:40 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#events P3 normal --- 13499 1 contributor ian annevk arun bugs bzbarsky cam ian jonas me mike Ms2ger public-html-admin public-html-wg-issue-tracking travil public-html-bugzilla oldest_to_newest 51695 0 contributor 2011-07-28 21:47:17 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html Multipage: http://www.whatwg.org/C#events Complete: http://www.whatwg.org/c#events Comment: Using "Function?" for the on* IDL attribute type doesn't seem to match implementations on setting Posted from: 71.184.125.56 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110721 Firefox/8.0a1 51697 1 bzbarsky 2011-07-28 21:49:12 +0000 In particular, per current spec text this will throw on setting: document.body.onclick = 3; but what actually happens in Gecko is that the expando is just set to 3, and in Presto and WebKit this sets document.body.onclick to null.... I will probably implement this last in Gecko as well. 51699 2 bzbarsky 2011-07-28 21:50:32 +0000 Oh, and setting document.body.onclick = {}; actually leaves it set to that value in Chrome and Safari, while it looks like it's still null in Opera. What does IE do here? 51702 3 annevk 2011-07-28 21:53:48 +0000 So do these need to accept "any" in the Web IDL and if it is not a Function it just sets it to null? That would be unfortunate. 51703 4 cam 2011-07-28 21:56:15 +0000 (In reply to comment #3) > So do these need to accept "any" in the Web IDL and if it is not a Function it > just sets it to null? That would be unfortunate. If this behaviour is needed, then "cleaner" may be to leave them as `Function?` but have some custom type coercion behaviour (specified by an extended attribute or some prose). 51704 5 bzbarsky 2011-07-28 22:01:40 +0000 Anne, that depends. Again, what does IE do here? Starting to throw an exception in situations where no UA does right now would seem to be a non-starter to me. 51714 6 annevk 2011-07-28 23:16:25 +0000 IE allows setting it to an object (e.g. window.XMLHttpRequest, {}, document, etc.) but setting it to 3 or "string" keeps the value as null. Seems like it matches WebKit? 51715 7 travil 2011-07-28 23:48:06 +0000 IE9's IDL attribute event handlers appear to accept Function, Object, Array, and DOM object instances, but nothing else (String, RegExp, Number, Boolean, etc.). I'm not sure why; I'll try to get back to you on this... 51717 8 bzbarsky 2011-07-28 23:56:02 +0000 > but setting it to 3 or "string" keeps the value as null. Keeps, or sets? That is, if you set it to a Function and then set to 3, do you get null, or the function that you set it to first? In any case, it sounds like throwing on non-Functions is a non-starter since no implementation does it... 51718 9 annevk 2011-07-29 00:01:04 +0000 Sets, sorry. 51723 10 bzbarsky 2011-07-29 02:09:25 +0000 For what it's worth, my current plan for Gecko is to set the handler to the given object if the given object is callable, and set it to null otherwise. 51887 11 cam 2011-08-01 04:06:32 +0000 Is there a need for this assume-null-if-assigned-thing-is-wrong behaviour for any non-Function attributes? (I.e. is it something we want to change in the normal ES->IDL conversion rules?) Ian: can you file a bug on Web IDL if you need a mechanism to select this non-standard coercion behaviour, thanks. 51898 12 annevk 2011-08-01 11:36:29 +0000 Filed bug 13499 on Web IDL. 51905 13 bzbarsky 2011-08-01 15:06:49 +0000 It's not even clear that we need this weirdness for all Function attributes. Or are on* the only Function attributes around? 51926 14 cam 2011-08-01 21:33:37 +0000 I believe they are the only uses of Function. 51928 15 travil 2011-08-01 21:45:09 +0000 ...the IE behavior I mentined in Comment 7 is happening due to an implementation-specific binding. The intent of the binding is to store JS functions, but due to implementation details, it also happens to store the other types as well. When an unsupported assignment is made to the IDL attribute, the currently stored handler is thrown out and the property is re-set back to null. We made an additional change to IE9 to _not_ support string assignments, which is a behavior that existed in IE8. I think we were going for a behavior match with HTML5 at the time. 51981 16 annevk 2011-08-02 11:25:22 +0000 It seems this behavior is not just used for Function. I get the same behavior for EventListener. Is this a problem with callbacks? 51987 17 bzbarsky 2011-08-02 13:39:49 +0000 > I get the same behavior for EventListener. Tested how? This script: try { document.addEventListener(3, "load", false); } catch (e) { alert(e); } shows a conversion failure exception in Gecko, as expected, and has all along. So I doubt sites depend on it working, unlike the on* case. 51989 18 annevk 2011-08-02 13:44:10 +0000 It does not throw in either Opera or WebKit. Not sure about IE. 51998 19 travil 2011-08-02 16:17:34 +0000 Doesn't throw in IE9 either. 52030 20 cam 2011-08-02 22:58:29 +0000 Whether addEventListener should be defined as void addEventListener(in DOMString a, in EventListener b, in bool c); or void addEventListener(in DOMString a, [FunkyNullHandling] in EventListener? b, in bool c); I guess is more of a problem for DOM Core. If we can go with the exception throwing mode, I think we should do so. I don't think the handling of non-object values is something we particularly want to propagate for new APIs, either, so I would rather introduce an extended attribute to allow this behaviour only on specific attributes and operation arguments. 52090 21 annevk 2011-08-03 05:37:14 +0000 By the way, please prefix the features that should not be propagated with "Legacy" or "Compat" or some such. E.g. stringifying null to "" is an example of that I think. 53948 22 mike 2011-08-04 05:34:44 +0000 mass-move component to LC1 57522 23 ian 2011-09-29 21:01:34 +0000 This should presumably also be fixed everywhere else 57523 24 contributor 2011-09-29 21:02:20 +0000 Checked in as WHATWG revision r6599. Check-in comment: Event handler IDL attribute compatibility WebIDL fix. http://html5.org/tools/web-apps-tracker?from=6598&to=6599 57549 25 annevk 2011-09-30 09:03:06 +0000 Given how often we use event handler attributes in the platform "[TreatNonCallableAsNull] Function?" is really rather ugly. We can maybe not introduce a "DOMEventHandler" type or some such in Web IDL for this? 57585 26 ian 2011-09-30 19:53:20 +0000 I'm not particularly worried about the verbosity here. It's pretty harmless. But if the syntax changes, just pass this potato back to me before it gets resolved. :-) (Reassigning to Anne per comment 23.) 57613 27 Ms2ger 2011-10-01 09:09:19 +0000 XHR: bug 14351 IDB: bug 14352 File API: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0010.html 57716 28 arun 2011-10-03 18:45:24 +0000 (In reply to comment #27) > XHR: bug 14351 > IDB: bug 14352 > File API: > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0010.html Made the change in File API editor's draft: http://dev.w3.org/2006/webapi/FileAPI/ (Goal is to arrive at a LCWD by October 12). 58279 29 cam 2011-10-16 03:49:09 +0000 (In reply to comment #25) > Given how often we use event handler attributes in the platform > > "[TreatNonCallableAsNull] Function?" > > is really rather ugly. We can maybe not introduce a "DOMEventHandler" type or > some such in Web IDL for this? BTW I was thinking of making typedefs propagate the extended attributes that appear on them, so that this kind of thing could be factored out nicely. For example: typedef [TreatNonCallableAsNull] Function? DOMEventHandler; 58280 30 annevk 2011-10-16 05:46:40 +0000 Sounds great! Also useful for [TreatNullAs=...] and such.