Starting with Firefox 130.0.1 the default installation of Firefox cannot be found by geckodriver

[JianPengChen]

when i update the firefox version, run the code,the geckodriver.exe no work,pls help m

[whimboo]

When you update Firefox nothing will change for geckodriver. Did you check where Firefox is installed? Has something changed? Which OS are you running? Please specify all the details.

[rlh-wgit]

We noticed this as well with upgrade from Firefox 130.0.0.2283 to Firefox 130.0.1.967. It seems something is broken related to detecting the default binary installation location (or if the browser provides that information to the driver somehow?) as the installation location did not change from one version to the other (still in C:\Program Files\Mozilla Firefox\firefox.exe in both versions)

As a workaround if you pass the BinaryLocation to the driver it will launch without the error.

[whimboo]

From a first look there is nothing contained in the 130.0.1 release which could have changed that. Are you using the official release of Firefox from mozilla.org? I wonder because of the version number you posted. We use 130.0.1, so where do the 2283 and 967 revision numbers come from?

Can you please try again when having trace-level logs for geckodriver enabled? I would be interested to know what's causing that and trace logs might give an indication. Thank you!

[datguyhjallewille]

I also have this issue as of today with version 130.0.1. I have updated geckodriver to the latest (0.35.0), but it did not help.

[whimboo]

Which kind of Windows flavor do you all have? Is it 32bit or 64bit?

Nevertheless please provide a trace level log as requested above while we are trying to reproduce. Thanks.

[Geremm]

Hello I have the same probleme on a Windows 64bit. I Use geckodriver on a python script and it tell me this :

Traceback (most recent call last):
File "C:\Users\Gérémy\Documents\cours\Info\python\Chaussure_Notif_Telegram\Main.py", line 22, in
driver = webdriver.Firefox(service=service, options=options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Gérémy\Documents\cours\Info\python\Chaussure_Notif_Telegram.venv\Lib\site-packages\selenium\webdriver\firefox\webdriver.py", line 57, in init
if finder.get_browser_path():
^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Gérémy\Documents\cours\Info\python\Chaussure_Notif_Telegram.venv\Lib\site-packages\selenium\webdriver\common\driver_finder.py", line 47, in get_browser_path
return self._binary_paths()["browser_path"]
^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Gérémy\Documents\cours\Info\python\Chaussure_Notif_Telegram.venv\Lib\site-packages\selenium\webdriver\common\driver_finder.py", line 78, in _binary_paths
raise NoSuchDriverException(msg) from err
selenium.common.exceptions.NoSuchDriverException: Message: Unable to obtain driver for firefox; For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors/driver_location

If you have an idea of what I can do I would be grateful.

[JJSoftwareCoder]

I'm using Selenium WebDriver 3.141.0 and Selenium.WebDriver.GeckoDriver.Win64 as nuget packages in a long established .Net Framework 4.71 project on Windows 10 22H2 (OS build 19045.4984) which has been working well for a good few years, but has started giving this same error once Firefox updated itself to version 130.0.1 (64 bit). When I set the Gecko log level to Trace I got the following output, which doesn't give much additional information:

1727127890304 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"session not created","message":"Expected browser binary location, but unable to find binary in default location, no 'moz:firefoxOptions.binary' capability provided, and no binary flag set on the command line","stacktrace":""}}

Interestingly, I spotted that my Firefox is installed to "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" despite being a 64 bit version. I suspect this may be because my development machine initially had the 32 bit version of Firefox but, if I remember correctly, Firefox switched over to the 64 bit version automatically some years ago. When I specified this (x86) location for the Firefox browser executable using the FirefoxOptions.BrowserExecutableLocation property Selenium and Gecko both ran successfully again. Could it be that some change in the latest version of Firefox has prevented Gecko from looking in the x86 folder structure even though a 64 bit executable is expected?

I hope this provides some helpful information to identify what's going on here, but at least I've found a solution for my C# project.

[nitingupta2]

I'm facing the same issue while running an R script.

> Selenium message:Expected browser binary location, but unable to find binary in default location, no 'moz:firefoxOptions.binary' capability provided, and no binary flag set on the command line
> Build info: version: '4.0.0-alpha-2', revision: 'f148142cf8', time: '2019-07-01T21:30:10'
> System info: host: 'XXXXXX', ip: '192.168.12.144', os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '1.8.0_181'
> Driver info: driver.version: unknown
> remote stacktrace: 
> 
> Could not open firefox browser.
> Client error message:
> 	 Summary: SessionNotCreatedException
>  	 Detail: A new session could not be created.
> 	 Further Details: run errorDetails method
> Check server log for further details.
> 

What option needs to be set in makeFirefoxProfile to find the location to the executable?

[whimboo]

Can anyone who is affected by this please try to use geckodriver directly from a terminal? Therefore please follow these steps:

1. Open a terminal and start geckodriver with the arguments -vv
2. geckodriver is now listening on localhost:4444
3. Open another terminal to manually start a WebDriver session. Therefore use eg. curl to send the HTTP JSON request like: curl -H 'Content-Type: application/json' -d '{"capabilities": {"alwaysMatch": {"acceptInsecureCerts": true}}}' http://localhost:4444/session.

Does that work or is geckodriver not able to find Firefox? If it cannot find Firefox please provide the following details:

• Version of Windows (including 32bit or 64bit)
• Version of geckodriver (32bit or 64bit)
• Version of Firefox (32bit or 64bit) and installation path

Thanks.

[rey-dominique]

Hello,
The problem is not in geckodriver but in Firefox 130.0 see https://bugzilla.mozilla.org/show_bug.cgi?id=1919569
The problem is the registry keys that are at the wrong place HKCU instead of HKLM after the upgrade to 130.0.1
The workaround can be just reinstalling Firefox from mozilla.org (without loosing FF config)

[whimboo]

Oh, this is a very helpful hint! Thanks @rey-dominique. Even through the keys aren't expected in HKCU I wonder if we should check that path as fallback. But lets wait what the outcome of the bug fix is.

[rey-dominique]

Yes, I had exactly the same problem as you.
I opened the incident on bugzilla because I found the the keys that was always in HKLM was deleted and added in HKCU when we do an upgrade from 130.0 to 130.0.1 and that is an error. The same type of error was more or less corrected in 129.0 !! but now back in 130.0.1 !!
This is only we you do an upgrade of Firefox to 130.0.1 but not when you do an installation or re-installation, the keys are in the correct place HKLM as usual and geckodriver / selenium are working well.

[whimboo]

FYI I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1921933 so that we can add support that geckodriver will also check HKCU in the future.

Given that this issue is for Firefox and affects not that many people we don't consider this addition as a fix. As such I'm closing this issue now.