/selenium

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performing a click by sending a POST-request on /session/{id}/click doesn’t seem to work with standalone selenium server v3.6.0 #4786

Closed
Rinzwind opened this Issue Sep 29, 2017 · 3 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
2 participants
@Rinzwind @p0deje
@Rinzwind

Rinzwind commented Sep 29, 2017 •
edited

Meta

OS: macOS 10.13
Selenium Version: selenium-server-standalone-3.6.0.jar
Browser: Chrome 61.0.3163.100

Description

Performing a click by sending a POST-request on /session/{id}/click doesn't seem to work with selenium-server-standalone-3.6.0.jar although it does work with
selenium-server-standalone-3.4.0.jar.

Details

Sample HTML:

<body onload="onLoad()">
	Did not click yet.
	<script type="text/javascript">
		/*<![CDATA[*/function onLoad(){window.onclick = function() { document.body.innerHTML = "Clicked!" };};/*]]>*/
	</script>
</body>

With v3.6.0 I'm getting the following output for a simple test that performs a click and checks whether the page text changes to “Clicked!”. Note that, as can be seen on the last line, the text remains “Did not click yet”:

13:36:12.163 INFO - Selenium Server is up and running
2017-09-29 13:36:15.976:INFO:osjshC.ROOT:qtp942731712-10: org.openqa.selenium.remote.server.WebDriverServlet-59fa1d9b: Initialising WebDriverServlet
13:36:16.082 INFO - Binding default provider to: org.openqa.selenium.chrome.ChromeDriverService
13:36:16.084 INFO - Found handler: org.openqa.selenium.remote.server.commandhandler.BeginSession@24824115
13:36:16.094 INFO - /session: Executing POST on /session (handler: BeginSession)
13:36:16.215 INFO - Capabilities are: Capabilities {browserName=chrome}
13:36:16.221 INFO - Capabilities {browserName=chrome} matched class org.openqa.selenium.remote.server.ServicedSession$Factory (provider: org.openqa.selenium.chrome.ChromeDriverService)
13:36:16.223 INFO - Capabilities {browserName=chrome} matched class org.openqa.selenium.remote.server.ServicedSession$Factory (provider: org.openqa.selenium.chrome.ChromeDriverService)
Starting ChromeDriver 2.32.498537 (cb2f855cbc7b82e20387eaf9a43f6b99b6105061) on port 36071
Only local connections are allowed.
13:36:23.308 INFO - Found handler: org.openqa.selenium.remote.server.ServicedSession@4ca51c04
13:36:23.309 INFO - Handler thread for session 2a8577a1573050d0c026c850ca3d3727 (chrome): Executing POST on /session/2a8577a1573050d0c026c850ca3d3727/url (handler: ServicedSession)
13:36:23.313 INFO - To upstream: {"url":"http://localhost:8080/WDTest/"}
13:36:24.248 INFO - To downstream: {"sessionId":"2a8577a1573050d0c026c850ca3d3727","status":0,"value":null}
13:36:24.252 INFO - Found handler: org.openqa.selenium.remote.server.ServicedSession@4ca51c04
13:36:24.254 INFO - Handler thread for session 2a8577a1573050d0c026c850ca3d3727 (chrome): Executing POST on /session/2a8577a1573050d0c026c850ca3d3727/element (handler: ServicedSession)
13:36:24.256 INFO - To upstream: {"using":"tag name","value":"body"}
13:36:24.409 INFO - To downstream: {"sessionId":"2a8577a1573050d0c026c850ca3d3727","status":0,"value":{"ELEMENT":"0.0800977203926796-1"}}
13:36:24.413 INFO - Found handler: org.openqa.selenium.remote.server.ServicedSession@4ca51c04
13:36:24.414 INFO - Handler thread for session 2a8577a1573050d0c026c850ca3d3727 (chrome): Executing GET on /session/2a8577a1573050d0c026c850ca3d3727/element/0.0800977203926796-1/text (handler: ServicedSession)
13:36:24.486 INFO - To downstream: {"sessionId":"2a8577a1573050d0c026c850ca3d3727","status":0,"value":"Did not click yet."}
13:36:24.490 INFO - Found handler: org.openqa.selenium.remote.server.ServicedSession@4ca51c04
13:36:24.491 INFO - Handler thread for session 2a8577a1573050d0c026c850ca3d3727 (chrome): Executing POST on /session/2a8577a1573050d0c026c850ca3d3727/click (handler: ServicedSession)
13:36:24.492 INFO - To upstream: {"button":1}
13:36:24.512 INFO - To downstream: {"sessionId":"2a8577a1573050d0c026c850ca3d3727","status":0,"value":null}
13:36:24.515 INFO - Found handler: org.openqa.selenium.remote.server.ServicedSession@4ca51c04
13:36:24.515 INFO - Handler thread for session 2a8577a1573050d0c026c850ca3d3727 (chrome): Executing GET on /session/2a8577a1573050d0c026c850ca3d3727/element/0.0800977203926796-1/text (handler: ServicedSession)
13:36:24.529 INFO - To downstream: {"sessionId":"2a8577a1573050d0c026c850ca3d3727","status":0,"value":"Did not click yet."}

With v3.4.0 I’m getting the following output for the same test. In this case, the text did change (though this is not as obvious from the log):

13:40:47.957 INFO - Selenium Server is up and running
13:40:50.425 INFO - SessionCleaner initialized with insideBrowserTimeout 0 and clientGoneTimeout 1800000 polling every 180000
13:40:50.470 INFO - Executing: [new session: Capabilities [{browserName=chrome}]])
13:40:50.504 INFO - Creating a new session for Capabilities [{browserName=chrome}]
Starting ChromeDriver 2.32.498537 (cb2f855cbc7b82e20387eaf9a43f6b99b6105061) on port 29406
Only local connections are allowed.
13:40:54.792 INFO - Detected dialect: OSS
13:40:54.856 INFO - Done: [new session: Capabilities [{browserName=chrome}]]
13:40:54.878 INFO - Executing: [get: http://localhost:8080/WDTest/])
13:40:55.457 INFO - Done: [get: http://localhost:8080/WDTest/]
13:40:55.507 INFO - Executing: [find element: By.tagName: body])
13:40:55.615 INFO - Done: [find element: By.tagName: body]
13:40:55.637 INFO - Executing: [get text: 0 [[ChromeDriver: chrome on MAC (11193c310f90e802c636e39aaba4c5d8)] -> tag name: body]])
13:40:55.695 INFO - Done: [get text: 0 [[ChromeDriver: chrome on MAC (11193c310f90e802c636e39aaba4c5d8)] -> tag name: body]]
13:40:55.700 INFO - Executing: [click: nothing])
13:40:55.722 INFO - Done: [click: nothing]
13:40:55.731 INFO - Executing: [get text: 0 [[ChromeDriver: chrome on MAC (11193c310f90e802c636e39aaba4c5d8)] -> tag name: body]])
13:40:55.755 INFO - Done: [get text: 0 [[ChromeDriver: chrome on MAC (11193c310f90e802c636e39aaba4c5d8)] -> tag name: body]]

I’m not quite sure whether this is a bug in selenium-server-standalone-3.6.0.jar, or whether there’s another problem. My apologies for not providing this as a more readily runnable scenario (though it is available as a test for the Beach Parasol framework).

@p0deje p0deje added the C-server label Sep 29, 2017

@p0deje

This comment has been minimized.

Show comment
Hide comment
@p0deje

p0deje Oct 1, 2017

Member

I'm not sure why it used to work correctly, but I see that you send the following payload:

{"button":1}

Per JSON wire protocol, it means to click with mouse middle-button. I don't know if onclick should be triggered upon middle-mouse button click (Google tells it varies per browsers), but it is definitely triggered upon left button click.

I can reproduce the issue by using the following payload:

$ curl -X POST -d '{"button": 1}' http://127.0.0.1:4444/wd/hub/session/fe9e46282b3d9414a7cdb9b7d41a1cc3/click
{"sessionId":"fe9e46282b3d9414a7cdb9b7d41a1cc3","status":0,"value":null}

However, the issue doesn't reproduce when correct mouse button is used:

$ curl -X POST -d '{"button": 0}' http://127.0.0.1:4444/wd/hub/session/fe9e46282b3d9414a7cdb9b7d41a1cc3/click
{"sessionId":"fe9e46282b3d9414a7cdb9b7d41a1cc3","status":0,"value":null}

With that said, I guess the bindings (Parasol) needs to be changed to use correct mouse button.

I'm going to close this now as it looks be 3rd party problem, but feel free to comment here if I got it wrong and I'll re-open the issue.
Member

p0deje commented Oct 1, 2017

I'm not sure why it used to work correctly, but I see that you send the following payload:

{"button":1}

Per JSON wire protocol, it means to click with mouse middle-button. I don't know if onclick should be triggered upon middle-mouse button click (Google tells it varies per browsers), but it is definitely triggered upon left button click.

I can reproduce the issue by using the following payload:

$ curl -X POST -d '{"button": 1}' http://127.0.0.1:4444/wd/hub/session/fe9e46282b3d9414a7cdb9b7d41a1cc3/click
{"sessionId":"fe9e46282b3d9414a7cdb9b7d41a1cc3","status":0,"value":null}

However, the issue doesn't reproduce when correct mouse button is used:

$ curl -X POST -d '{"button": 0}' http://127.0.0.1:4444/wd/hub/session/fe9e46282b3d9414a7cdb9b7d41a1cc3/click
{"sessionId":"fe9e46282b3d9414a7cdb9b7d41a1cc3","status":0,"value":null}

With that said, I guess the bindings (Parasol) needs to be changed to use correct mouse button.

I'm going to close this now as it looks be 3rd party problem, but feel free to comment here if I got it wrong and I'll re-open the issue.

@p0deje p0deje closed this Oct 1, 2017

Rinzwind pushed a commit to SeasideSt/Parasol that referenced this issue Oct 2, 2017

Kris
Fixed wrong button number for BPClickAction in #click and #click:atOf… 
…fset: in BPActions (see: SeleniumHQ/selenium#4786 (comment)).
a2d71b6
@Rinzwind

This comment has been minimized.

Show comment
Hide comment
@Rinzwind

Rinzwind Oct 2, 2017

Oops, sorry about that, totally didn't notice that the button number was wrong (though, oddly, the test did still give the expected result when using selenium server v3.4.0). It has been fixed now in Parasol.

Rinzwind commented Oct 2, 2017

Oops, sorry about that, totally didn't notice that the button number was wrong (though, oddly, the test did still give the expected result when using selenium server v3.4.0). It has been fixed now in Parasol.
@p0deje

This comment has been minimized.

Show comment
Hide comment
@p0deje

p0deje Oct 2, 2017

Member

Since 3.5 server started to simply pass through all the requests to end driver without doing any intermediate conversions. I believe that is the reason - maybe at some point server was transforming the button number or doing something like that.

In any event, send left button is the correct way.
Member

p0deje commented Oct 2, 2017

Since 3.5 server started to simply pass through all the requests to end driver without doing any intermediate conversions. I believe that is the reason - maybe at some point server was transforming the button number or doing something like that.

In any event, send left button is the correct way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment