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.

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?

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.

(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).

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.

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?

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...

> 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...

Sets, sorry.

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.

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.

Filed bug 13499 on Web IDL.

It's not even clear that we need this weirdness for all Function attributes.

Or are on* the only Function attributes around?

I believe they are the only uses of Function.

...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.

It seems this behavior is not just used for Function. I get the same behavior for EventListener. Is this a problem with callbacks?

> 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.

It does not throw in either Opera or WebKit. Not sure about IE.

Doesn't throw in IE9 either.

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.

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.

mass-move component to LC1

This should presumably also be fixed everywhere else 

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

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?

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.)

XHR: bug 14351
IDB: bug 14352
File API: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0010.html

(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).

(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;

Sounds great! Also useful for [TreatNullAs=...] and such.