FindElement on Firefox & .NET Core very slow

[fraser-lowndes]

🐛 Bug Report

When targeting netcoreapp*.* e.g. netcoreapp2.2 and using FirefoxDriver, most actions are incredibly slow.
When targeting net*** e.g. net461 and performing the same actions, the speed is as-expected (in the tens of milliseconds)

When targeting either framework, the speed of Chrome remains low & consistent.

This appears to be related to a number of issues (#6597, #5676, #4988) however all these relate to use of localhost, whereas my problem occurrs when using google.com.

SSCCE: https://github.com/fraser-lowndes/selenium-issue-7840

Example output when targeting netcoreapp2.2:

... [firefox driver init] ...
FirefoxDriver FindElement time: 2033.2775ms
FirefoxDriver Element.Displayed time: 2076.6096ms
... [chrome driver init] ...
ChromeDriver FindElement time: 16.7848ms
ChromeDriver Element.Displayed time: 57.7246ms

OS: Windows 10 build 18362.476
Browser: Firefox
Browser version: 70.0.1
Browser Driver version: Firefox.WebDriver 0.26.0
Language Bindings version: C# 3.141.0

[jimevans]

This is the same root cause as the other issues you’ve referenced. The detail that the site being browsed is hosted on the internet vs. hosted on localhost are immaterial to the bug, as even though the browser is communicating to the remote site, the language bindings (your C# code) are still communicating with geckodriver over an HTTP connection on localhost. The bug is in the interaction between the .NET Core networking stack, and geckodriver. Note that the geckodriver issue also has an associate issue logged in Mozilla’s tracker for Firefox itself.

You can work around the issue by forcing geckodriver to listen on the IPv6 loopback (::1) using the Host property of the FirefoxDriverService. To wit:

FirefoxDriverService service = FirefoxDriverService.CreateDefaultService();
service.Host = "::1";
IWebDriver driver = new FirefoxDriver(service);

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.