User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0.1 Build ID: 20120905151427 Steps to reproduce: 1. Load http://jsfiddle.net/BVKPf/1/show 2. Click where it says "click me" Actual results: NS_ERROR_XPC_BAD_OP_ON_WN_PROTO: Illegal operation on WrappedNative prototype object Expected results: change the content of the #eventType element to "click"

Confirmed behaviour exists on 18.0a1 (2012-09-11)

Per WebIDL, this should throw. See http://dev.w3.org/2006/webapi/WebIDL/#es-attributes step 2 substep 2.2 under "The attribute getter".

And yes, the exact exception being thrown is not quite right; there are existing bugs on that.

Boris, The only other browser that throws is IE. Can you provide clarification as to _why_ event objects should fall under the behaviour outlined in substep 2.2? Copying event objects is both a common and expensive task when it must be done with a for-in loop, it would be nice if the spec wasn't trying to make it harder to cope with...

> The only other browser that throws is IE. For attribute getters, yes. For method calls, everyone except Chrome throws (or at least IE, Firefox, Safari, and Opera all throw). The specification went with the simpler behavior of having attributes and methods behave the same way instead of defining different behaviors for them. Especially since the simpler behavior was demonstrably web-compatible (in that IE ships it). > Can you provide clarification as to _why_ event objects should fall under the behaviour > outlined in substep 2.2? Because http://www.w3.org/TR/domcore/#dependencies says the DOM uses WebIDL and hence http://www.w3.org/TR/domcore/#interface-event is a WebIDL interface and hence the rules of WebIDL apply. Unless you're asking something else, like why this particular section of the WebIDL spec applies to this particular situation? > Copying event objects is both a common and expensive task when it must be done with a > for-in loop, it would be nice if the spec wasn't trying to make it harder to cope > with... It's not clear what the spec makes harder here, exactly... The best course of action if you think the spec should change is to send feedback to public-script-coord@w3.org explaining your use case (the thing you're really trying to do, not the specific approach you're taking to doing it) and why the spec should change to handle it better. Then we can have this discussion with a clear use case before us, and with representatives from the other browser vendors involved.

Boris, Thanks for clarifying all of this, much appreciated.

One other note: for attribute _setters_, I believe the current behavior in the setup here is that IE and Firefox throw, Chrome bizarrely applies the setter to the wrong this object, and Opera and Safari totally violate the ES spec and don't invoke the setter at all, instead creating an own property on the this object(!). Hence the specification went with the simple (and sane, unlike most of the above) behavior of throwing for setters, because the other options just made no sense. So the real question you want to answer in your mail to public-script-coord should be: given that setters and methods throw, why shouldn't getters, exactly?

Great - thanks again for the additional info :)

No problem. I just wish there were better interop here. ;)

I’ll be sending this to public-script-coord in the next couple of days to try to solicit some additional feedback. I appreciate the implementation-sanity of the current proposal, but as a JS author, it is important to me to be able to have a way to augment DOM event objects and/or override select properties in a time- and memory-efficient manner. Right now, most script libraries end up doing a shallow copy of properties from the native event object to a surrogate and then fix up the standard event methods (stopPropagation, etc.) to point back to the native object, which is quite inefficient. Delegation could be a more reasonable way to accomplish this, but this change to Web IDL spec (and Firefox) makes it impossible. Ultimately I suppose that ES6 proxies will be the solution here, but it sucks how limited we are now. My personal feeling is that browser vendors should be trying to make host objects indistinguishable from native JavaScript objects as much as possible, and this change seems to go in the opposite direction. Cheers,

Just to be clear, this is not a change in WebIDL. WebIDL has basically said this all along... It _is_ a change in behavior for Firefox, to align with WebIDL. Also to significantly increase performance of DOM getters, for what it's worth.