Values returned by webdrivers

Asked 21/1, 2018 at 16:54 Answered 16/2, 2018 at 23:47

Solved selenium webdriver chrome-web-driver

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?

Despain answered 21/1, 2018 at 16:54 Comment(1)

The former Selenium 2 protocol used the key ELEMENT to store the reference of a DOM element. This key was changed with the Selenium 3 protocol to element-6066-11e4-a52e-4f735466ce. Though most of the implementation of the current chromedriver is still from the Selenium 2 spec. – Spheroidicity 22/1, 2018 at 16:17

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.

Acidimetry answered 22/1, 2018 at 12:3 Comment(3)

I am confused. I asked about the format of the /session/{session id}/element webdriver call in browsers.. ? – Despain 22/1, 2018 at 12:16

Added an update to my Answer. Let me know if you have counter questions. – Acidimetry 22/1, 2018 at 13:29

I have one last question about this... any hints...? – Despain 23/1, 2018 at 9:50

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

Pluri answered 16/2, 2018 at 23:47 Comment(4)

Yep, I had it all worked out. Which is why I ended up developing best-webdriver ... have a look! – Despain 17/2, 2018 at 3:51

Very impressive, nice to see such a clear implementation for a change. – Pluri 18/2, 2018 at 3:28

I should be able to write a hub too, in just under 400 lines of code. This means that you can do distributed testing without touching java/selenium... – Despain 18/2, 2018 at 6:46

The only REAL show-stopper is that Chrome doesn't implement actions. This limits how viable best-webdriver is -- Selenium's API does a LOT to simulate "actions"; I don't want to go down that path, especially since they will be implemented soon enough anyway. (Plus, Selenium's implementation has its limitations) – Despain 18/2, 2018 at 6:48

Browser Specific Implementation

Update A

Update B

Recommended topics

Hot tags