selenium: [π Bug]: Current version of chrome is not supporting by Selenium Manager
What happened?
I was trying to simply open chrome browser and open a website. But i am getting an error on my console. OS: Windows Editor: Pycharm Language: Python
Note: Firefox browser is working fine with the new feature of Selenium Manager
How can we reproduce the issue?
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("https://www.google.com/")
Relevant log output
Traceback (most recent call last):
File "C:\Users\jeet\PycharmProjects\NufDemo\tests\Sel_New_Fea.py", line 3, in <module>
driver = webdriver.Chrome()
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\chrome\webdriver.py", line 81, in __init__
super().__init__(
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\chromium\webdriver.py", line 106, in __init__
super().__init__(
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 288, in __init__
self.start_session(capabilities, browser_profile)
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 381, in start_session
response = self.execute(Command.NEW_SESSION, parameters)
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 444, in execute
self.error_handler.check_response(response)
File "C:\Users\jeet\PycharmProjects\NufDemo\venv\lib\site-packages\selenium\webdriver\remote\errorhandler.py", line 249, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.SessionNotCreatedException: Message: session not created: This version of ChromeDriver only supports Chrome version 96
Current browser version is 107.0.5304.107 with binary path C:\Program Files\Google\Chrome\Application\chrome.exe
Stacktrace:
Backtrace:
Ordinal0 [0x00946903+2517251]
Ordinal0 [0x008DF8E1+2095329]
Ordinal0 [0x007E2848+1058888]
Ordinal0 [0x00800B9D+1182621]
Ordinal0 [0x007FCA60+1165920]
Ordinal0 [0x007FA2CF+1155791]
Ordinal0 [0x0082AAAF+1354415]
Ordinal0 [0x0082A71A+1353498]
Ordinal0 [0x0082639B+1336219]
Ordinal0 [0x008027A7+1189799]
Ordinal0 [0x00803609+1193481]
GetHandleVerifier [0x00AD5904+1577972]
GetHandleVerifier [0x00B80B97+2279047]
GetHandleVerifier [0x009D6D09+534521]
GetHandleVerifier [0x009D5DB9+530601]
Ordinal0 [0x008E4FF9+2117625]
Ordinal0 [0x008E98A8+2136232]
Ordinal0 [0x008E99E2+2136546]
Ordinal0 [0x008F3541+2176321]
BaseThreadInitThunk [0x763AFEF9+25]
RtlGetAppContainerNamedObjectPath [0x77C37BBE+286]
RtlGetAppContainerNamedObjectPath [0x77C37B8E+238]
Operating System
Windows 10
Selenium version
Selenium 4.6.0
What are the browser(s) and version(s) where you see this issue?
Chrome 107.0.5304.107
What are the browser driver(s) and version(s) where you see this issue?
No driver has been used
Are you using Selenium Grid?
No
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (10 by maintainers)
It is easy to implement that Selenium Manager processes the PATH, so we can do it. As I see it, Selenium Manager can discover if a driver is in the path and if the version is suitable to drive the browser. If the driver is not compatible (typically, since it is an old version), IMO, Selenium Manager should fix the problem (i.e., resolve the proper driver and ignore the driver in the PATH).
Then, we can also log a
WARNin Selenium Manager about it (something similar to mention, e.g., βyou have an old version of <chromedriver> β¦ etc.β). In that case, thatWARNtrace should also be parsed in the bindings and logged to the final user again.My attempt was to give some insight on the issue. I have an open source library using selenium 4.6, about 40 percent of people who used the new version that is packing selenium 4.6 faced this issue where selenium detects and older version of chrome driver vs the one that is being used.
I too suspect that this is caused by some leftover chrome drivers in the system/PATH. Considering most of the adopters will have some version of chrome driver installed somewhere, it makes sense to debug this.
Thanks for clarifying.
Yeah, there are several options for how we could move forward with this.
My preference right now is for 2, but weβre not ready for that, yet, either.