This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In several ways: It is defined in both executeScript and executeAsyncScript rather than in a single place It seems to think that a javascript function is going to return an IDL type, which it isn't. This causes several problems: * DOMString is considered a possible return type, which it isn't, but a javascript string isn't, which it is * Similarly with long and Number * sequences of Nodes aren't a possible return type, although arrays in general are. It seems like Document Element is apparently being used to mean "Element", which is very unclear since a Document is not an Element. Corresponding webelement needs to be a reference. Arrays should probably be treated specially so that any array input results in an array output. It is unclear how you are iterating over objects. Are only own properties considered, or do you flatten the prototype chain? ES will have an algorithm to hook into here. The possibility of cyclic objects and indefinite recursion is not considered. You need to do something sensible in this case. You might want to examine the algorithm at [1] which implements many of the same ideas. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data
Oh and you need to consider the possibility that the algorithm throws because you can define a property like {get foo: function() {throw new TypeError()}}
WebIDL defines a mapping between WebIDL and Ecmascript - http://www.w3.org/TR/WebIDL/#es-type-mapping DOMString seems to be nearly the same as a string in Ecmascript Sequence seems to be nearly the same as array in Ecmascript Notes: 1. I haven't read WebIDL spec fully so I don't know if it's more appropriate to use WebIDL types or Ecmascript's when saying how "executeScript" should work 2. Most of the spec uses WebIDL types so if it will be decided to use Ecmascript's types here it should be properly noted in the spec that types in this section (and only in this section) refer to Ecmascript's types, not WebIDL's.
Using WebIDL only makes sense when describing interfaces. In this case there isn't an interface, there is just an algorithm that operates purely on JS types. Describing it in terms of WebIDL doesn't make any sense. It is quite possible that there are other places in the spec using WebIDL for things that aren't interfaces. These uses are all wrong.
*** Bug 26228 has been marked as a duplicate of this bug. ***
And what is the resolution?