SeleniumHQ / selenium-google-code-issue-archive

Archive, please see main selenium repo
https://github.com/seleniumhq/selenium
346 stars 194 forks source link

ParseJavaScriptReturnValue should NOT parse objects containing an id field as RemoteWebElement #8048

Open lukeis opened 8 years ago

lukeis commented 8 years ago

Originally reported on Google Code with ID 8048

This started happening in Selenium 2.43.0. The change responsible for this can be found
in dotnet/src/webdriver/Remote/RemoteWebDriver.cs, method private object ParseJavaScriptReturnValue(object
responseValue), line 1174.

In 2.42.2, resultAsDictionary would only be treated as a RemoteWebElement if it contained
the key "ELEMENT". In 2.43.0, it is also treated as a RemoteWebElement if it contains
the key "id".

This is a problem because there are a lot of things that use objects with an "id" field.
In my particular case, the website's dataLayer has an array[] that contains an object
with an id field, among other values. This was requested by a third party tracker to
do various analytics on our traffic. As it is implemented now in 2.43.0, ExecuteScript("return
dataLayer;") will return the RemoteWebElement, with an id value, but everything else
gets lost.

I can imagine this isn't the only case. I've found quite a few people complaining about
this but not knowing why it's happening while I was googling for a cause. I'm hoping
someone agrees that "id" is too generic to assume it's a RemoteWebElement object and
removes it.

Reported by razvan.s.dicu on 2014-10-16 07:36:25

lukeis commented 8 years ago
This behavior was introduced to accommodate the behavio of the IE driver implementation
provided by Microsoft. The revision of the W3C WebDriver specification on which the
implementation was based documented that element serialization should occur with the
field name of "id" in the JSON payload instead of the proper "ELEMENT". This has been
corrected in the spec, and for exactly the reason you state, that "id" is simply too
common to assume a WebElement has been serialized, However, Microsoft has not yet released
an update to their driver implementation, so removing this hack would render their
driver implementation unusable. 

Reported by james.h.evans.jr on 2014-10-16 10:25:10

lukeis commented 8 years ago
Hi James,

Thanks for clarifying that. Glad to hear the change is in the works!

Cheers,

Reported by razvan.s.dicu on 2014-10-16 10:30:46

lukeis commented 8 years ago

Reported by barancev on 2014-10-19 11:22:54

lukeis commented 8 years ago

Reported by luke.semerau on 2015-09-17 17:47:30