[🐛 Bug]: FirefoxDriverService.cs one line change breaks geckodriver ConnectToRunningBrowser

What happened?

[dotnet] Add --websocket-port command line argument for geckodriver argsBuilder.Append(string.Format(CultureInfo.InvariantCulture, " --websocket-port {0}", PortUtilities.FindFreePort()));

This breaks the firefoxdriver ability to connect to an already open browser when using --connect-existing.

geckodriver: The argument ‘–connect-existing’ cannot be used with '–websocket-port

The websocket-port should not be blindly added when all the other parms are conditional…

How can we reproduce the issue?

FirefoxDriverService firefoxDriverService = FirefoxDriverService.CreateDefaultService(browserSettings.DriverLocation);
                    firefoxDriverService.HideCommandPromptWindow = false;
                    firefoxDriverService.Port = 0;
                    firefoxDriverService.BrowserCommunicationPort = 2828;
                    firefoxDriverService.Host = "127.0.0.1";
                    firefoxDriverService.ConnectToRunningBrowser = true;
                    var tmpDriver = new FirefoxDriver(firefoxDriverService, ffOptions);

Relevant log output

geckodriver: The argument '--connect-existing' cannot be used with '--websocket-port

Operating System

win 10

Selenium version

latest

What are the browser(s) and version(s) where you see this issue?

firefox

What are the browser driver(s) and version(s) where you see this issue?

most recent geckodriver

Are you using Selenium Grid?

No response

[deadmike]

@jimevans I didn’t state any malice. Intentional is exactly what the change was, however the implementation was flawed.

i’ve developed code since 1986, it’s why I know about this bug. every single bug i’ve ever written and will write is all intentional, never any malice implied, but honestly speaking, every bug is intended for some purpose that it misses to fulfill. the code is intentionally written, albeit without me realizing it was buggy.

[jimevans]

Okay, yes, I see that it’s a bug. Contrary to @deadmike‘s assertion, this break was not intentional; it was done inadvertently with a misunderstanding of how the bidi port should be applied. Without it, none of the new Selenium 4 bidi-based features (network interception, JavaScript console monitoring, etc.) will work for Firefox. I’m sure you’re willing to live with the trade off, so I’ll reopen the issue. I get the frustration, but the assertion of malice and intent, and the accompanying tone, is entirely unwarranted.