c# - Selenium WebDriver throws Timeout exceptions sporadically

Question

Using selenium for ui tests on our project. We are running the newest version 2.30.0. We use Firefox WebDriver and are running Firefox 19.0.

Generally said the ui test works local and even server side when I run the ui test in Visual Studio. Our ui tests gets executed nighlty on our build server. It uses the same deploy on the same server I test manually via Visual Studio.

But sporadically we run into following issue when the ui test gets executed on buildserver:

Test(s) failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL http://localhost:7056/hub/session/bed1d0e7-efdc-46b6-ba07-34903519c44d/element/%7B8717bb19-96c7-44d3-b0ee-d4b989ae652d%7D/click timed out after 60 seconds.
      ----> System.Net.WebException : The operation has timed out
       at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
       at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
--WebException
   at System.Net.HttpWebRequest.GetResponse()
   at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)

Basically the test clicks on an upload button where the input field was filled with a file before. Since the file is very small this gets done in a few seconds. Nevertheless the timout of 60 seconds is reached sometimes.

Any ideas how to isolate the underlying issue? Or run anybody into the same issue before? Any hints appreciated. Thanks.

Answer 1

I got this same error: .NET WebDriver: 2.37, FF: 25.0.1. I noticed that Firefox was locking up until I exited my test application, so I built the debug version of Firefox and found that the lock-up happened when it was writing to stderr. This gave me the clue to change the webdriver code so that it no longer redirects standard out and error and this solved my problem. It seems like the WebDriver is blocking the std error in some way. From MSDN:

Synchronous read operations introduce a dependency between the caller reading from the StandardError stream and the child process writing to that stream. These dependencies can cause deadlock conditions...

More info here.

For anyone wanting to make the same tweak I did: -

1. Get the Selenium source. Then check out the same code branch that you are using.

2. In FireFoxBinary.cs:

   i. Wherever you find RedirectStandardError = true, change to RedirectStandardError = false.

   ii. Wherever you find RedirectStandardOutput = true, change to RedirectStandardOutput = false. (for non-Windows, there is also one in Executable.cs)

   iii. In ConsoleOuput, change 'return this.stream.ReadToEnd()', to 'return ""'

3. Build and replace WebDriver.dll with yours.

Disclaimer: This worked for me, but your issue might be different. Also as far as I can tell, this has no adverse effects other than disabling the console output, but there may be other side effects that I am unaware of.

I would be interested to know if anyone else finds the same.

Since I have solved my problem, I will not dig any deeper. If anyone a Selenium group member wants more info / logs / tweaks I would be happy to do so.

Hopefully this will get fixed soon.

Update

It appears that Firefox v25 is not currently supported. See this comment.

Update 25th Feb 2014

See this update:

Okay, this issue in general does not manifest itself in IE, or so it seems from the comments. I'd like people to try with Firefox and Chrome, and the .NET bindings 2.40.0 (will be the next release at the time of this writing) or later, and see if this is still happening.

I've seen fewer reports of this happening in Chrome since 2.35.0, so I need to know if this is still an issue with the .NET bindings and a recent chromedriver.exe.

2.40.0 may have a fix for at least one of the issues that may cause this in Firefox.

This solved the problem for me. Looking at the change log, there is a commit from 1/31/2014 to remove console logging redirection:

"No longer redirecting console output for Firefox in .NET bindings."

Which is the workaround I used here. So, it all makes sense.