OS:
Windows 8.1
Selenium Version:
3.4.0
Browser:
Chrome, Firefox (does not look like browser dependent)
Browser Version:
Chrome 58.0.3029.110 (64-bit)
Remote driver connection
WebDriverException
I have a simple Selenium Grid remote driver initialization which is failing with an WebDriverException as below:
from selenium import webdriver
from selenium.webdriver.support import expected_conditions as EC
selenium_grid_url='http://localhost:4444/wd/hub'
caps = webdriver.DesiredCapabilities.FIREFOX.copy()
caps['platform']="WINDOWS"
caps['version']="8.1"
remotedriver = webdriver.Remote(desired_capabilities=caps,
command_executor=selenium_grid_url)
I get the following error:
Traceback (most recent call last): File "D:/Selenium/ChromeBrowser/loginscript.py", line 16, in command_executor=selenium_grid_url) File "D:\Python\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 98, in init self.start_session(desired_capabilities, browser_profile) File "D:\Python\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 185, in start_session response = self.execute(Command.NEW_SESSION, parameters) File "D:\Python\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 249, in execute self.error_handler.check_response(response) File "D:\Python\lib\site-packages\selenium\webdriver\remote\errorhandler.py", line 194, in check_response raise exception_class(message, screen, stacktrace) selenium.common.exceptions.WebDriverException: Message: None Stacktrace: at java.util.HashMap.putMapEntries (:-1) at java.util.HashMap.putAll (:-1) at org.openqa.selenium.remote.DesiredCapabilities. (DesiredCapabilities.java:55) at org.openqa.grid.web.servlet.handler.RequestHandler.process (RequestHandler.java:104) at org.openqa.grid.web.servlet.DriverServlet.process (DriverServlet.java:83) at org.openqa.grid.web.servlet.DriverServlet.doPost (DriverServlet.java:67) at javax.servlet.http.HttpServlet.service (HttpServlet.java:707) at javax.servlet.http.HttpServlet.service (HttpServlet.java:790) at org.seleniumhq.jetty9.servlet.ServletHolder.handle (ServletHolder.java:841) at org.seleniumhq.jetty9.servlet.ServletHandler.doHandle (ServletHandler.java:543) at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextHandle (ScopedHandler.java:188) at org.seleniumhq.jetty9.server.session.SessionHandler.doHandle (SessionHandler.java:1584) at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextHandle (ScopedHandler.java:188) at org.seleniumhq.jetty9.server.handler.ContextHandler.doHandle (ContextHandler.java:1228) at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope (ScopedHandler.java:168) at org.seleniumhq.jetty9.servlet.ServletHandler.doScope (ServletHandler.java:481) at org.seleniumhq.jetty9.server.session.SessionHandler.doScope (SessionHandler.java:1553) at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope (ScopedHandler.java:166) at org.seleniumhq.jetty9.server.handler.ContextHandler.doScope (ContextHandler.java:1130) at org.seleniumhq.jetty9.server.handler.ScopedHandler.handle (ScopedHandler.java:141) at org.seleniumhq.jetty9.server.handler.HandlerWrapper.handle (HandlerWrapper.java:132) at org.seleniumhq.jetty9.server.Server.handle (Server.java:564) at org.seleniumhq.jetty9.server.HttpChannel.handle (HttpChannel.java:320) at org.seleniumhq.jetty9.server.HttpConnection.onFillable (HttpConnection.java:251) at org.seleniumhq.jetty9.io.AbstractConnection$ReadCallback.succeeded (AbstractConnection.java:279) at org.seleniumhq.jetty9.io.FillInterest.fillable (FillInterest.java:112) at org.seleniumhq.jetty9.io.ChannelEndPoint$2.run (ChannelEndPoint.java:124) at org.seleniumhq.jetty9.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:672) at org.seleniumhq.jetty9.util.thread.QueuedThreadPool$2.run (QueuedThreadPool.java:590) at java.lang.Thread.run (:-1)
Process finished with exit code 1
Java version 1.8.0 (121)
Both hub and node of the grid on the same machine.
Python version 3.5.2
Duplicate of #3808
There's no details / information provided as to why this is a duplicate of #3808. There are no work-arounds provided as to how I could overcome this and move ahead with my work. I request further information on both.
FYI, in #3808, it's mentioned that one can workaround this issue by downgrading to 3.3.0. I see the same issue with my setup in Selenium 3.3.0 and Selenium 3.3.1 standalone versions too. So, I doubt if this is a duplicate. Please clarify.
The issue is that in 3.4, a JSON payload is used in the new session command with the following format:
{
"capabilities": {...},
"desiredCapabilities": {...}
}
This is correct with respect to the W3C WebDriver specification. Sending a payload of this format was introduced in the 3.4 language bindings, and not before. However, the grid hub incorrectly expects a payload of
{
"capabilities": {
"desiredCapabilities": {...}
}
}
What is distinctive about this case is that the response returned by the hub has no error information in its body, leading to the None in the resulting exception message. There is very little chance of any other root cause to this symptom. Moreover, the problematic code in the grid hub predates the 3.4 release, and indeed has been there for many months and released prior. Simply rolling back the standalone server versions to 3.3.x is insufficient as a workaround; one must roll back the language bindings as well.
If you are able to provide information that contradicts this analysis, feel free to provide it. Does this provide enough information and clarification to satisfy your request and quell your doubt that this is a duplicate of that issue, or do you require further convincing?
I seem to have fixed this locally for myself by changing line 183 of webdriver.py
old:
parameters = {"capabilities": w3c_caps,
"desiredCapabilities": capabilities}
new:
parameters = {"desiredCapabilities": capabilities}
I'm quite obviously losing the "w3c_caps" data here, but for my usage this is completely meaningless.
is there an ETA on when this change will be implemented in the actual python package?
Also running into this issue. Temporary fix from @LeeorV works, which makes @jimevans explanation of the issue very likely.
+1 to this, facing the same issue and @LeeorV workaround works. Any ETA to fix this?
Most helpful comment
I seem to have fixed this locally for myself by changing line 183 of webdriver.py
old:
parameters = {"capabilities": w3c_caps,
"desiredCapabilities": capabilities}
new:
parameters = {"desiredCapabilities": capabilities}
I'm quite obviously losing the "w3c_caps" data here, but for my usage this is completely meaningless.
is there an ETA on when this change will be implemented in the actual python package?