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".
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
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 firstname.lastname@example.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. ;)
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.
You need to log in before you can comment on or make changes to this bug.