CODEWITHSUNDEEP
seleniumwebdriverchrome-web-driver
Merc
Merc

Reputation: 17057

Values returned by webdrivers

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' }

Upvotes: 2

Views: 1195

Answers (2)

undetected Selenium
undetected Selenium

Reputation: 193068

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.

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.

Upvotes: 2

scipilot
scipilot

Reputation: 7447

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

Upvotes: 0

Related Questions