Values returned by webdrivers

Question

After performing a search using POST /session/{session id}/element, I get this from the Chrome webdriver:

{ sessionId: '3241e7da289f4feb19c1f55dfc87024b',
  status: 0,
  value: { ELEMENT: '0.12239552668870868-1' } }

Is this what the specs demand?

I am asking because I couldn't find anywhere a spot where it said clearly "ELEMENT" in capital letters. All I can find in the specs is that a key called value is set (which it is: it's set as { ELEMENT: '0.12239552668870868-1' }

• Can I always always expect this response, from other browsers' webdrivers? That is, are status and sessionId always returned?

• Is that { ELEMENT: '0.12239552668870868-1' } the way chromium makes up the object? Or is this true for any webdrivers? Of not, what do other webdrivers return?

Answer 1

The WebDriver-W3C Candidate Recommendation clearly mentions the following points:

• The Find Element command is used to find an element in the current browsing context that can be used for future commands.
• Let location strategy be the result of getting a property called "using".
• Let selector be the result of getting a property called "value".
• The result of getting a property with argument name is defined as being the same as the result of calling Object.GetOwnProperty(propertyName).
• GetOwnProperty(propertyName) in ECMAScript® Language Specification is defined as :

String objects use a variation of the GetOwnProperty internal method used for other native ECMAScript objects. This special internal method provides access to named properties corresponding to the individual characters of String objects.

• So invoking GetOwnProperty are internal method used for other native ECMAScript objects and are resolved within the internal scope of the Browser Drivers and Browser Clients.
• Mozilla have well documented Object.getOwnPropertyNames() and getOwnPropertyDescriptors().

---

Browser Specific Implementation

I did a small test with all the info you have provided with Search Box of Google Home Page i.e. https://www.google.co.in with all the major variants of WebDrivers and here is the result :

• ChromeDriver - OSS :

  [[ChromeDriver: chrome on XP (0d24fd038bde751b1e411711271c3e69)] -> name: q]
  [[ChromeDriver: chrome on XP (0d24fd038bde751b1e411711271c3e69)] -> name: q]
  

• FirefoxDriver - W3C :

  [[FirefoxDriver: firefox on XP (e7a56813-97c5-466e-9c35-24c9f89af6ed)] -> name: q]
  [[FirefoxDriver: firefox on XP (e7a56813-97c5-466e-9c35-24c9f89af6ed)] -> name: q]
  

• InternetExplorerDriver - W3C :

  [[InternetExplorerDriver: internet explorer on WINDOWS (367257db-cdbc-4be7-aeac-805a21ad9d2d)] -> name: q]
  [[InternetExplorerDriver: internet explorer on WINDOWS (367257db-cdbc-4be7-aeac-805a21ad9d2d)] -> name: q]
  

So as you can observe from the field details of the concerned value field returned is in similar pattern and till the WebDriver variant passes the correct reference to user it shouldn't be a obstacle.

Finally, it is worth to mention at this point of time that like FirefoxDriver and InternetExplorerDriver (both being W3C compliant), ChromeDriver is almost W3C compliant and may vary from a few functional aspects.

---

Update A

As per your question and update, you are pretty right about ChromeDriver and Chrome communication protocol. Getting more granular we can find some difference in the webdriver call as follows :

• Firefox :

  1516626575533   webdriver::server   DEBUG   <- 200 OK {"value":{"element-6066-11e4-a52e-4f735466cecf":"6e35faa4-233f-400c-a6c7-6a66b54a69e5"}}
  

So, Firefox Browser returns :

"value":{"element-6066-11e4-a52e-4f735466cecf":"6e35faa4-233f-400c-a6c7-6a66b54a69e5"}

• Chrome :

          [14.921][DEBUG]: DEVTOOLS RESPONSE Runtime.evaluate (id=25) {
     "result": {
        "type": "object",
        "value": {
           "status": 0,
           "value": {
              "ELEMENT": "0.7086986861512812-1"
           }
        }
     }
  }
  

So, Chrome Browser returns :

"value": {"ELEMENT": "0.7086986861512812-1"}

What matters most to we user is the value of the element returned by the browser object which is always referred by an user and correctly identified by the webdriver instance. All these inner logic becomes abstract to the end user.

---

Update B

Adding some significant bytes from @FlorentB. 's comments :

The earlier versions of Selenium i.e. Selenium v2.x used the keyword ELEMENT to store the reference of a DOM Tree element. This key was changed within the recent versions of Selenium i.e. Selenium v3.x to element-6066-11e4-a52e-4f735466ce. Most of the implementation of the current ChromeDriver is still from the Selenium 2.x specifications.

Answer 2

I have just encountered this same issue, and found the change was made around 3.5 of the Selenium server and related images.

I found this comment the most specific to understand the change and identify which version it changed in: https://github.com/SeleniumHQ/selenium/issues/4773#issuecomment-333092149

I am using Docker images like selenium/node-firefox:3.4.0-actinium, and have found v3.4.0 returns the ELEMENT key from the older JSonWire spec, whereas v3.9 returns the format element-6066-11e4-a52e-4f735466cecf from the new WebDriver spec. (I haven't checked any other versions in between).

It's part of their gradual migration to WebDriver, but it is a bit confusing that they did this breaking change at 3.5 (or thereabouts) and not v3.0.0 which I think everyone would have been OK with.

Also there's a mix of implementations in the "native" drivers like Gecko which is produced by the Firefox team now, and Chrome, as they will have different development roadmaps.

Furthermore, I've found the client-side library I'm using hasn't even implemented the new response yet, so I'll have to hang back for a while (or patch and PR it myself). I've seen similar conversations in other clients (like the Java client 2 years ago).

You can see the differences between the two protocols' definitions of the Element response:

https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol#webelement-json-object

https://www.w3.org/TR/webdriver/#elements