[🐛 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

[bonigarcia]

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 WARN in Selenium Manager about it (something similar to mention, e.g., “you have an old version of <chromedriver> … etc.”). In that case, that WARN trace should also be parsed in the bindings and logged to the final user again.

[titusfortner]

Thanks for clarifying.

Yeah, there are several options for how we could move forward with this.

1. Have users opt-in to using Selenium Manager in the code somehow (similar to WDM)
2. Have Selenium Manager first locate/use drivers on PATH (better errors and auto-fixes)
3. Have Selenium Manager ignore what’s on PATH and just download what it needs

My preference right now is for 2, but we’re not ready for that, yet, either.