26137 2014-06-18 22:05:45 +0000 [WebDriver Spec]: Algorithm for serializing a result is broken 2016-12-13 20:27:36 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified PC Linux RESOLVED FIXED P2 normal --- 20860 1 james public-browser-tools-testing barancev botalov.andrey lrekucki mike public-browser-tools-testing oldest_to_newest 108036 0 james 2014-06-18 22:05:45 +0000 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 108037 1 james 2014-06-18 22:09:05 +0000 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()}} 108273 2 botalov.andrey 2014-06-24 14:00:31 +0000 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. 108274 3 james 2014-06-24 14:06:22 +0000 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. 108452 4 james 2014-06-28 08:08:39 +0000 *** Bug 26228 has been marked as a duplicate of this bug. *** 128319 5 barancev 2016-12-13 20:27:36 +0000 And what is the resolution?