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 13433 - Event handler IDL attributes need [TreatNonCallableAsNull]
Summary: Event handler IDL attributes need [TreatNonCallableAsNull]
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on: 13499
  Show dependency treegraph
Reported: 2011-07-28 21:47 UTC by contributor
Modified: 2011-10-16 05:46 UTC (History)
13 users (show)

See Also:


Description contributor 2011-07-28 21:47:17 UTC

Using "Function?" for the on* IDL attribute type doesn't seem to match
implementations on setting

Posted from:
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110721 Firefox/8.0a1
Comment 1 Boris Zbarsky 2011-07-28 21:49:12 UTC
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.
Comment 2 Boris Zbarsky 2011-07-28 21:50:32 UTC
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?
Comment 3 Anne 2011-07-28 21:53:48 UTC
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.
Comment 4 Cameron McCormack 2011-07-28 21:56:15 UTC
(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).
Comment 5 Boris Zbarsky 2011-07-28 22:01:40 UTC
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.
Comment 6 Anne 2011-07-28 23:16:25 UTC
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?
Comment 7 Travis Leithead [MSFT] 2011-07-28 23:48:06 UTC
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...
Comment 8 Boris Zbarsky 2011-07-28 23:56:02 UTC
> 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...
Comment 9 Anne 2011-07-29 00:01:04 UTC
Sets, sorry.
Comment 10 Boris Zbarsky 2011-07-29 02:09:25 UTC
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.
Comment 11 Cameron McCormack 2011-08-01 04:06:32 UTC
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.
Comment 12 Anne 2011-08-01 11:36:29 UTC
Filed bug 13499 on Web IDL.
Comment 13 Boris Zbarsky 2011-08-01 15:06:49 UTC
It's not even clear that we need this weirdness for all Function attributes.

Or are on* the only Function attributes around?
Comment 14 Cameron McCormack 2011-08-01 21:33:37 UTC
I believe they are the only uses of Function.
Comment 15 Travis Leithead [MSFT] 2011-08-01 21:45:09 UTC
...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.
Comment 16 Anne 2011-08-02 11:25:22 UTC
It seems this behavior is not just used for Function. I get the same behavior for EventListener. Is this a problem with callbacks?
Comment 17 Boris Zbarsky 2011-08-02 13:39:49 UTC
> I get the same behavior for EventListener.

Tested how?  This script:

    try {
      document.addEventListener(3, "load", false);
    } catch (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.
Comment 18 Anne 2011-08-02 13:44:10 UTC
It does not throw in either Opera or WebKit. Not sure about IE.
Comment 19 Travis Leithead [MSFT] 2011-08-02 16:17:34 UTC
Doesn't throw in IE9 either.
Comment 20 Cameron McCormack 2011-08-02 22:58:29 UTC
Whether addEventListener should be defined as

  void addEventListener(in DOMString a, in EventListener b, in bool c);


  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.
Comment 21 Anne 2011-08-03 05:37:14 UTC
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.
Comment 22 Michael[tm] Smith 2011-08-04 05:34:44 UTC
mass-move component to LC1
Comment 23 Ian 'Hixie' Hickson 2011-09-29 21:01:34 UTC
This should presumably also be fixed everywhere else 
Comment 24 contributor 2011-09-29 21:02:20 UTC
Checked in as WHATWG revision r6599.
Check-in comment: Event handler IDL attribute compatibility WebIDL fix.
Comment 25 Anne 2011-09-30 09:03:06 UTC
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?
Comment 26 Ian 'Hixie' Hickson 2011-09-30 19:53:20 UTC
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.)
Comment 28 Arun 2011-10-03 18:45:24 UTC
(In reply to comment #27)
> XHR: bug 14351
> IDB: bug 14352
> File API:

Made the change in File API editor's draft:

(Goal is to arrive at a LCWD by October 12).
Comment 29 Cameron McCormack 2011-10-16 03:49:09 UTC
(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;
Comment 30 Anne 2011-10-16 05:46:40 UTC
Sounds great! Also useful for [TreatNullAs=...] and such.