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
This is the same root cause as the other issues you鈥檝e 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鈥檚 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);
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.
Most helpful comment
This is the same root cause as the other issues you鈥檝e 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鈥檚 tracker for Firefox itself.You can work around the issue by forcing geckodriver to listen on the IPv6 loopback (
::1) using theHostproperty of theFirefoxDriverService. To wit: