This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 9.1 states that the WebElement interface has an attribute named "id". Thus, when serialized, a reference to an element when returned from a JavaScript execution would look like this: {"id": "<element id>"} Now consider returning a JavaScript object literal with the following JSON definition: {"id": "this is my super ID value"} It will be impossible to distinguish between a legitimate WebElement reference, and an object literal when evaluating the returned JSON value. The Selenium open-source project mitigates this by using a property name of "ELEMENT" instead of "id" for element references. Using "id" is problematic, merely because there are any number of uses for returning an object with an "id" property. Renaming the property to something like "webdriverElementId" would likely resolve the issue.
Adding an additional concrete example using Java from the existing OSS project language bindings: JavascriptExecutor executor = (JavascriptExecutor)driver; // Can value1 be cast to a WebElement in the Java bindings? // It should be able to, because that's what it represents. Object value1 = executor.executeScript("return document.getElementById('foo');"); // value2 should be castable to a Map<String, Object>, because // we're returning an object literal, but how can the language // binding know that the result *isn't* a WebElement. There's // no way to tell the difference by looking only at the serialized // JSON response. Object value2 = executor.executeScript("return { \"id\": \"this is my fake element id\" };");
This will be updated as http://www.w3.org/2014/07/07-testing-minutes.html#action25
https://dvcs.w3.org/hg/webdriver/rev/d81488ae4045 I did not update section 14 with this patch as that section is currently being rewritten after f2f in London