selenium-google-code-issue-archive icon indicating copy to clipboard operation
selenium-google-code-issue-archive copied to clipboard

ParseJavaScriptReturnValue should NOT parse objects containing an id field as RemoteWebElement

Open lukeis opened this issue 8 years ago • 4 comments

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 avatar Mar 04 '16 09:03 lukeis

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

  • Status changed: Accepted
  • Labels removed: Status-Untriaged

lukeis avatar Mar 04 '16 09:03 lukeis

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 avatar Mar 04 '16 09:03 lukeis

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

  • Labels added: Browser-IE

lukeis avatar Mar 04 '16 09:03 lukeis

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

  • Labels added: Restrict-AddIssueComment-Commit

lukeis avatar Mar 04 '16 09:03 lukeis