RemoteWebDriver uses POST method for Get Active Element

[andreastt]

As is shown by the stacktrace in mozilla/geckodriver#223, Selenium uses the POST method when getting the current active element. It should use GET according to the specification.

I think this is a problem in the RemoteWebDriver, but I’m not sure.

[mb73]

I think I have found the bug in the source code of AbstractHttpCommandCodec:

defineCommand(GET_ACTIVE_ELEMENT, post("/session/:sessionId/element/active"));
should be
defineCommand(GET_ACTIVE_ELEMENT, get("/session/:sessionId/element/active"));

not?

[andreastt]

That looks like it, yes. But it needs to be special cased for when speaking to a W3C conformant remote as not to break backwards compatibility with Selenium remotes.

[mb73]

My guess is that the other remotes just take anything, no matter if get or post. So I would suggest to just try it. If all of them are happy with “get”, then simply change it.

[andreastt]

I think that’s a bold assumption to make. I’m quite sure chromedriver is explicit about what HTTP methods it listens to, but I’m most willing to be proved wrong on this.

[mb73]

Really? It sounds so weird to me to expect someone to “post” for getting some information. However, thanks for the feedback :)

[andreastt]

It is weird as you say, because this command doesn’t have any state-altering behaviour. This is incidentally why we’ve rectified it in the specification.

I dug into this and it looks like chromedriver accepts only POST for /session/{session id}/element/active: https://cs.chromium.org/chromium/src/chrome/test/chromedriver/server/http_handler.cc?q=http+file:%5Esrc/chrome/test/chromedriver/&sq=package:chromium&dr=CSs&l=214

[jleyba]

It's post because it modifies server state. For w3c spec they decided to go
against http recommendations and use get as it's more descriptive of the
action
On Mon, Sep 26, 2016 at 6:48 AM mb73 notifications@github.com wrote:

Really? It sounds so weird to me to expect someone to “post” for getting
some information. However, thanks for the feedback :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2751 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPkCWLH2yiuv55o-lFieU0SinoAEOGiks5qt80ogaJpZM4J5MTh
.

[mb73]

Now I’m curious. Which state is modified by “Get Active Element”?

[jleyba]

It's the same as find element: the server has to generate a web element
reference
On Mon, Sep 26, 2016 at 6:56 AM mb73 notifications@github.com wrote:

Now I’m curious. Which state is modified by “Get Active Element”?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#2751 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPkCdgsWVTc7flZ-OQ7ZpxJ9bjMx9ANks5qt88ZgaJpZM4J5MTh
.

[mb73]

And that reference exists beyond the request? If so: why? Thanks for your patience with me :)

[jleyba]

That's how you interact with dom elements with webdriver. You get a web
element reference with an opaque ID generated by the server. Subsequent
commands reference that ID so the server knows what DOM element you are
actually trying to interact with
On Mon, Sep 26, 2016 at 7:01 AM mb73 notifications@github.com wrote:

And that reference exists beyond the request? If so: why? Thanks for your
patience with me :)

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#2751 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPkCSaOgsqMY9nvUOVrpVD28lBAVtNKks5qt9AjgaJpZM4J5MTh
.

[jleyba]

How does it not alter state? See my previous comments. The server has to
generate a new webelement if it's the first time the "active" element is
retrieved
On Mon, Sep 26, 2016 at 7:04 AM Andreas Tolfsen notifications@github.com
wrote:

It is weird as you say, because this command doesn’t have any
state-altering behaviour. This is incidentally why we’ve rectified it in
the specification.

I dug into this and it looks like chromedriver accepts only POST for /session/{session
id}/element/active:
https://cs.chromium.org/chromium/src/chrome/test/chromedriver/server/http_handler.cc?q=http+file:%5Esrc/chrome/test/chromedriver/&sq=package:chromium&dr=CSs&l=214

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2751 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPkCbVEFeyYt573jcRHfypDf5u90uKNks5qt830gaJpZM4J5MTh
.

[mb73]

It’s probably because I have no idea about how such a server works, but it sounds like an implementation detail to me if such reference / ID exists in the first place or is generated as a side effect of “Get Active Element”.

[andreastt]

To be clear, whether it alters state depends on the implementation. You could imagine an implementation that generates web element UUIDs for all DOM elements when it is under WebDriver control.

Does it alter state in existing implementations? Well the most correct answer is “maybe”. If you ask for the active element and it has not been fetched previously, most drivers will hash it and create a new web element reference as jleyba explains. If it already exists in the set of known web elements it does not alter any state and it is a straight table lookup operation.

However, I’m not sure I entirely agree that generating a web element reference amounts to “modifying server state”. The primitive that is accessed is document.activeElement, which is a getter.

[jleyba]

Look at it another way: get active element is equivalent to executeScript("return document.activeElement"); (a POST). You can also use findElement with CSS (also a POST). For HTML, there doesn't even need to be a dedicated command for this (it's probably justified for mobile implementations like appium, but I have separate reservations about mapping WebDriver's API to native applications).

I'm not trying to argue that the w3c should change from GET, just pointing out that the wire protocol's use of POST isn't as off base as has been suggested.

[andreastt]

The reason finding an element and executing scripts require POST is because we need to send a body, which is not the case for getting the active element, though.

Of course I’m not arguing that any of this makes sense if you view this with RESTful goggles. I think it’s fair to say it’s an approximation to providing a “RESTish” API. 😄

[lukeis]

fixed in java... needs fixing in the other languages as well

[shs96c]

This is a w3c spec conformance issue. Moved to the 4.0 milestone

[mb73]

I’m confused. This is a huge blocker. How can anyone test with Firefox as long as this is not fixed?
If you need an example: http://stackoverflow.com/questions/39570283/selenium-3-submit-a-form-with-firefox

[andreastt]

@mb73 Do note that the Java bindings were fixed in ed15c6c.

[titusfortner]

Ruby has been compliant from the beginning, and this is a duplicate: #2555 :)

[mb73]

@andreastt Thank you! I’m happy to hear that postponing the issue doesn’t mean a rollback for the Java bindings.

[jimevans]

Fixed in .NET in 5e1d455