Last Comment Bug 790303 - NS_ERROR_XPC_BAD_OP_ON_WN_PROTO when using Object.create on an Event object as of Firefox 14
: NS_ERROR_XPC_BAD_OP_ON_WN_PROTO when using Object.create on an Event object a...
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 15 Branch
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: 622301
  Show dependency treegraph
 
Reported: 2012-09-11 10:13 PDT by Colin Snover
Modified: 2012-11-14 08:53 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Colin Snover 2012-09-11 10:13:53 PDT
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"
Comment 1 Rick Waldron [:rwaldron] 2012-09-11 11:10:18 PDT
Confirmed behaviour exists on 18.0a1 (2012-09-11)
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2012-09-11 14:56:13 PDT
Per WebIDL, this should throw.  See http://dev.w3.org/2006/webapi/WebIDL/#es-attributes step 2 substep 2.2 under "The attribute getter".
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2012-09-11 14:56:52 PDT
And yes, the exact exception being thrown is not quite right; there are existing bugs on that.
Comment 4 Rick Waldron [:rwaldron] 2012-09-11 17:19:41 PDT
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...
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2012-09-11 17:26:55 PDT
> 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.
Comment 6 Rick Waldron [:rwaldron] 2012-09-11 17:29:15 PDT
Boris, 

Thanks for clarifying all of this, much appreciated.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2012-09-11 17:32:15 PDT
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?
Comment 8 Rick Waldron [:rwaldron] 2012-09-11 17:36:13 PDT
Great - thanks again for the additional info :)
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2012-09-11 17:38:05 PDT
No problem.  I just wish there were better interop here.  ;)
Comment 10 Colin Snover 2012-09-11 20:30:30 PDT
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,
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2012-09-12 00:10:33 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.