Selenium Error - The HTTP request to the remote WebDriver timed out after 60 seconds
I've been using Selenium for a number of months, which we're using to automate some of our internal testing processes. The scripts have been passing fine. I've recently upgraded to C# 2.40.0 webdriver using FF 27.01 and our scripts are now failing in random places with the following error.
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
[09:01:20]
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
at OpenQA.Selenium.Support.UI.DefaultWait`1.PropagateExceptionIfNotIgnored(Exception e)
at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
at Portal.Test.Helpers.Process_Bookings.OpenBookings.SelectBooking(String bookingnumber)
at Portal.SmokeTest.SmokeRunTest.Booking() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 68
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--TearDown
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Firefox.Internal.ExtensionConnection.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
at OpenQA.Selenium.Remote.RemoteWebDriver.Close()
at Portal.Test.Helpers.Setup.CloseWebdriver()
at Portal.SmokeTest.SmokeRunTest.TearDown() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 162
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
The latest error I've managed to track down to one single line of code:
_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();
The annoying thing is, trying to fix the problem is proving difficult, as if I run the test on my local machine, in debug it passes. Additionally, if I run it via the NUNIT runner on the build machine I'm running the test off, it also passes. It only seems to fail as part of our automated build running process when using Teamcity. Like I said, this has been running fine for months previously, and the only thing that has changed is the selenium webdriver kit.
I have experienced this problem before, whilst in debug, and when a Click()
line of code was called, Firefox appeared to lock up, and only stopping the test would allow Firefox to continue. There are a number of suggestions on here including modifying the webdriver source? I'd like to not go down that route if possible if anyone else can offer any suggestions.
c# selenium selenium-webdriver nunit teamcity
add a comment |
I've been using Selenium for a number of months, which we're using to automate some of our internal testing processes. The scripts have been passing fine. I've recently upgraded to C# 2.40.0 webdriver using FF 27.01 and our scripts are now failing in random places with the following error.
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
[09:01:20]
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
at OpenQA.Selenium.Support.UI.DefaultWait`1.PropagateExceptionIfNotIgnored(Exception e)
at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
at Portal.Test.Helpers.Process_Bookings.OpenBookings.SelectBooking(String bookingnumber)
at Portal.SmokeTest.SmokeRunTest.Booking() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 68
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--TearDown
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Firefox.Internal.ExtensionConnection.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
at OpenQA.Selenium.Remote.RemoteWebDriver.Close()
at Portal.Test.Helpers.Setup.CloseWebdriver()
at Portal.SmokeTest.SmokeRunTest.TearDown() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 162
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
The latest error I've managed to track down to one single line of code:
_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();
The annoying thing is, trying to fix the problem is proving difficult, as if I run the test on my local machine, in debug it passes. Additionally, if I run it via the NUNIT runner on the build machine I'm running the test off, it also passes. It only seems to fail as part of our automated build running process when using Teamcity. Like I said, this has been running fine for months previously, and the only thing that has changed is the selenium webdriver kit.
I have experienced this problem before, whilst in debug, and when a Click()
line of code was called, Firefox appeared to lock up, and only stopping the test would allow Firefox to continue. There are a number of suggestions on here including modifying the webdriver source? I'd like to not go down that route if possible if anyone else can offer any suggestions.
c# selenium selenium-webdriver nunit teamcity
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59
add a comment |
I've been using Selenium for a number of months, which we're using to automate some of our internal testing processes. The scripts have been passing fine. I've recently upgraded to C# 2.40.0 webdriver using FF 27.01 and our scripts are now failing in random places with the following error.
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
[09:01:20]
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
at OpenQA.Selenium.Support.UI.DefaultWait`1.PropagateExceptionIfNotIgnored(Exception e)
at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
at Portal.Test.Helpers.Process_Bookings.OpenBookings.SelectBooking(String bookingnumber)
at Portal.SmokeTest.SmokeRunTest.Booking() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 68
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--TearDown
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Firefox.Internal.ExtensionConnection.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
at OpenQA.Selenium.Remote.RemoteWebDriver.Close()
at Portal.Test.Helpers.Setup.CloseWebdriver()
at Portal.SmokeTest.SmokeRunTest.TearDown() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 162
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
The latest error I've managed to track down to one single line of code:
_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();
The annoying thing is, trying to fix the problem is proving difficult, as if I run the test on my local machine, in debug it passes. Additionally, if I run it via the NUNIT runner on the build machine I'm running the test off, it also passes. It only seems to fail as part of our automated build running process when using Teamcity. Like I said, this has been running fine for months previously, and the only thing that has changed is the selenium webdriver kit.
I have experienced this problem before, whilst in debug, and when a Click()
line of code was called, Firefox appeared to lock up, and only stopping the test would allow Firefox to continue. There are a number of suggestions on here including modifying the webdriver source? I'd like to not go down that route if possible if anyone else can offer any suggestions.
c# selenium selenium-webdriver nunit teamcity
I've been using Selenium for a number of months, which we're using to automate some of our internal testing processes. The scripts have been passing fine. I've recently upgraded to C# 2.40.0 webdriver using FF 27.01 and our scripts are now failing in random places with the following error.
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
[09:01:20]
[Portal.SmokeTest.SmokeRunTest.Booking] TearDown method failed. OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/element timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
TearDown : OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL htt(p)://localhost:7055/hub/session/56e99e88-ba17-4d12-bef1-c6a6367ccc2f/window timed out after 60 seconds.
----> System.Net.WebException : The operation has timed out
at OpenQA.Selenium.Support.UI.DefaultWait`1.PropagateExceptionIfNotIgnored(Exception e)
at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
at Portal.Test.Helpers.Process_Bookings.OpenBookings.SelectBooking(String bookingnumber)
at Portal.SmokeTest.SmokeRunTest.Booking() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 68
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--TearDown
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Firefox.Internal.ExtensionConnection.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
at OpenQA.Selenium.Remote.RemoteWebDriver.Close()
at Portal.Test.Helpers.Setup.CloseWebdriver()
at Portal.SmokeTest.SmokeRunTest.TearDown() in d:TeamCityAgentworkdac1dcea7f2e80dfSmokeTestsSmokeRunTest.cs:line 162
--WebException
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
The latest error I've managed to track down to one single line of code:
_setup.driver.FindElement(By.XPath("//button[@class='buttonSmall lockBookingButton']")).Click();
The annoying thing is, trying to fix the problem is proving difficult, as if I run the test on my local machine, in debug it passes. Additionally, if I run it via the NUNIT runner on the build machine I'm running the test off, it also passes. It only seems to fail as part of our automated build running process when using Teamcity. Like I said, this has been running fine for months previously, and the only thing that has changed is the selenium webdriver kit.
I have experienced this problem before, whilst in debug, and when a Click()
line of code was called, Firefox appeared to lock up, and only stopping the test would allow Firefox to continue. There are a number of suggestions on here including modifying the webdriver source? I'd like to not go down that route if possible if anyone else can offer any suggestions.
c# selenium selenium-webdriver nunit teamcity
c# selenium selenium-webdriver nunit teamcity
edited Nov 26 '17 at 13:20
CK R
6361817
6361817
asked Mar 11 '14 at 10:13
NathanNathan
321133
321133
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59
add a comment |
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59
add a comment |
11 Answers
11
active
oldest
votes
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Launch your browser using the above lines of code. It worked for me.
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
add a comment |
I had a similar issue using the Chrome driver (v2.23) / running the tests thru TeamCity. I was able to fix the issue by adding the "no-sandbox" flag to the Chrome options:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
I'm not sure if there is a similar option for the FF driver. From what I understand the issue has something to do with TeamCity running Selenium under the SYSTEM account.
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
add a comment |
I first encountered this issue months ago (also on the click()
command), and it has been an issue for me ever since. It seems to be some sort of problem with the .NET Selenium bindings. This blog post by the guy that works on the IE driver is helpful in explaining what's happening:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Unfortunately, there doesn't seem to be a real solution to this problem. Whenever this issue has been raised to the Selenium developers (see here), this is a typical response:
We need a reproducible scenario, that must include a sample page or a link to a public site's page where the issue can be reproduced.
If you are able to submit a consistently reproducible test case, that could be very helpful in putting this bug to rest for good.
That said, perhaps you can try this workaround in the meantime. If the HTML button that you are trying to click()
has an onclick
attribute which contains Javascript, consider using a JavascriptExecutor to execute that code directly, rather than calling the click()
command. I found that executing the onclick
Javascript directly allows some of my tests to pass.
add a comment |
In my case, my button's type is submit
not button
and I change the Click
to Sumbit
then every work good. Something like below,
from driver.FindElement(By.Id("btnLogin")).Click();
to driver.FindElement(By.Id("btnLogin")).Submit();
BTW, I have been tried all the answer in this post but not work for me.
add a comment |
Got similar issue. Try to set more time in driver's constructor - add eg.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look likedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
add a comment |
In my case, it's because I deleted the chrome update folder. After chrome reinstall, it's working fine.
add a comment |
The problem is that the evaluation of Click()
times out on your build env.. you might want to dig into what happens on Click()
.
Also, try adding Retrys for the Click()
because occssionally the evaluations take longer time depending on network speeds, etc
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
add a comment |
I think this problem occurs when you try to access your web driver object after
1) a window has closed and you haven't yet switched to the parent
2) you switched to a window that wasn't quite ready and has been updated since you switched
waiting for the windowhandles.count
to be what you're expecting doesn't take into account the page content nor does document.ready. I'm still searching for a solution to this problem
add a comment |
In my case I found this error happening in our teams build server. The tests worked on our local dev machines.
The problem was that the target website was not configured correctly on the build server, so it couldn't open the browser correctly.
We were using the chrome driver but I'm not sure that makes a difference.
add a comment |
changing the Selenium.WebDriver.ChromeDriver from 2.40.0 to 2.27.0 is ok for me
add a comment |
For ChromDriver the below worked for me:
string chromeDriverDirectory = "C:\temp\2.37";
var options = new ChromeOptions();
options.AddArgument("-no-sandbox");
driver = new ChromeDriver(chromeDriverDirectory, options,
TimeSpan.FromMinutes(2));
Selenium version 3.11, ChromeDriver 2.37
add a comment |
protected by Community♦ May 18 '17 at 9:46
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Launch your browser using the above lines of code. It worked for me.
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
add a comment |
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Launch your browser using the above lines of code. It worked for me.
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
add a comment |
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Launch your browser using the above lines of code. It worked for me.
new FirefoxDriver(new FirefoxBinary(),new FirefoxProfile(),TimeSpan.FromSeconds(180));
Launch your browser using the above lines of code. It worked for me.
edited May 8 '15 at 6:07
Mackan
5,32021638
5,32021638
answered May 8 '15 at 4:22
user2298124user2298124
16613
16613
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
add a comment |
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
That sure fixed the issue. Thanks user2298124 and Mackan for sharing this info.
– windchaser
Jan 5 '17 at 14:27
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
Fixed for us as well. When running a basic script which just created a FF driver and nothing else, a 60 second timeout worked 100% of the time. When running our resource-heavy script, which opens connections to databases/reads/writes/does a lot more immediately before opening FF, a 60 timeout would cause failures ~50% of the time. Increasing the timeout to 3 minutes fixed the problem. Seems that Webdriver just needs a little more time to get the engine warmed up.
– KayakinKoder
Jun 30 '17 at 0:29
add a comment |
I had a similar issue using the Chrome driver (v2.23) / running the tests thru TeamCity. I was able to fix the issue by adding the "no-sandbox" flag to the Chrome options:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
I'm not sure if there is a similar option for the FF driver. From what I understand the issue has something to do with TeamCity running Selenium under the SYSTEM account.
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
add a comment |
I had a similar issue using the Chrome driver (v2.23) / running the tests thru TeamCity. I was able to fix the issue by adding the "no-sandbox" flag to the Chrome options:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
I'm not sure if there is a similar option for the FF driver. From what I understand the issue has something to do with TeamCity running Selenium under the SYSTEM account.
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
add a comment |
I had a similar issue using the Chrome driver (v2.23) / running the tests thru TeamCity. I was able to fix the issue by adding the "no-sandbox" flag to the Chrome options:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
I'm not sure if there is a similar option for the FF driver. From what I understand the issue has something to do with TeamCity running Selenium under the SYSTEM account.
I had a similar issue using the Chrome driver (v2.23) / running the tests thru TeamCity. I was able to fix the issue by adding the "no-sandbox" flag to the Chrome options:
var options = new ChromeOptions();
options.AddArgument("no-sandbox");
I'm not sure if there is a similar option for the FF driver. From what I understand the issue has something to do with TeamCity running Selenium under the SYSTEM account.
answered Sep 2 '16 at 19:57
combatc2combatc2
68347
68347
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
add a comment |
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
this solve my problem as well. I was unable to run chrome tests anymore after months of not trying them. Thanks combatc2
– Etienne
Jan 13 '17 at 19:00
1
1
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
My code was running fine in an IIS hosted env and stopped suddenly, but still worked in my unit tests. Adding this line made it work again in IIS env. Thanks!
– Legends
Feb 7 '18 at 16:48
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@Legends no problem - glad I could help!
– combatc2
Feb 8 '18 at 17:31
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
@combatc2 Thank you! This solved my problem!
– Naveen Dennis
May 17 '18 at 16:02
add a comment |
I first encountered this issue months ago (also on the click()
command), and it has been an issue for me ever since. It seems to be some sort of problem with the .NET Selenium bindings. This blog post by the guy that works on the IE driver is helpful in explaining what's happening:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Unfortunately, there doesn't seem to be a real solution to this problem. Whenever this issue has been raised to the Selenium developers (see here), this is a typical response:
We need a reproducible scenario, that must include a sample page or a link to a public site's page where the issue can be reproduced.
If you are able to submit a consistently reproducible test case, that could be very helpful in putting this bug to rest for good.
That said, perhaps you can try this workaround in the meantime. If the HTML button that you are trying to click()
has an onclick
attribute which contains Javascript, consider using a JavascriptExecutor to execute that code directly, rather than calling the click()
command. I found that executing the onclick
Javascript directly allows some of my tests to pass.
add a comment |
I first encountered this issue months ago (also on the click()
command), and it has been an issue for me ever since. It seems to be some sort of problem with the .NET Selenium bindings. This blog post by the guy that works on the IE driver is helpful in explaining what's happening:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Unfortunately, there doesn't seem to be a real solution to this problem. Whenever this issue has been raised to the Selenium developers (see here), this is a typical response:
We need a reproducible scenario, that must include a sample page or a link to a public site's page where the issue can be reproduced.
If you are able to submit a consistently reproducible test case, that could be very helpful in putting this bug to rest for good.
That said, perhaps you can try this workaround in the meantime. If the HTML button that you are trying to click()
has an onclick
attribute which contains Javascript, consider using a JavascriptExecutor to execute that code directly, rather than calling the click()
command. I found that executing the onclick
Javascript directly allows some of my tests to pass.
add a comment |
I first encountered this issue months ago (also on the click()
command), and it has been an issue for me ever since. It seems to be some sort of problem with the .NET Selenium bindings. This blog post by the guy that works on the IE driver is helpful in explaining what's happening:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Unfortunately, there doesn't seem to be a real solution to this problem. Whenever this issue has been raised to the Selenium developers (see here), this is a typical response:
We need a reproducible scenario, that must include a sample page or a link to a public site's page where the issue can be reproduced.
If you are able to submit a consistently reproducible test case, that could be very helpful in putting this bug to rest for good.
That said, perhaps you can try this workaround in the meantime. If the HTML button that you are trying to click()
has an onclick
attribute which contains Javascript, consider using a JavascriptExecutor to execute that code directly, rather than calling the click()
command. I found that executing the onclick
Javascript directly allows some of my tests to pass.
I first encountered this issue months ago (also on the click()
command), and it has been an issue for me ever since. It seems to be some sort of problem with the .NET Selenium bindings. This blog post by the guy that works on the IE driver is helpful in explaining what's happening:
http://jimevansmusic.blogspot.com/2012/11/net-bindings-whaddaymean-no-response.html
Unfortunately, there doesn't seem to be a real solution to this problem. Whenever this issue has been raised to the Selenium developers (see here), this is a typical response:
We need a reproducible scenario, that must include a sample page or a link to a public site's page where the issue can be reproduced.
If you are able to submit a consistently reproducible test case, that could be very helpful in putting this bug to rest for good.
That said, perhaps you can try this workaround in the meantime. If the HTML button that you are trying to click()
has an onclick
attribute which contains Javascript, consider using a JavascriptExecutor to execute that code directly, rather than calling the click()
command. I found that executing the onclick
Javascript directly allows some of my tests to pass.
answered Apr 17 '14 at 15:49
Daniel CharlesDaniel Charles
310212
310212
add a comment |
add a comment |
In my case, my button's type is submit
not button
and I change the Click
to Sumbit
then every work good. Something like below,
from driver.FindElement(By.Id("btnLogin")).Click();
to driver.FindElement(By.Id("btnLogin")).Submit();
BTW, I have been tried all the answer in this post but not work for me.
add a comment |
In my case, my button's type is submit
not button
and I change the Click
to Sumbit
then every work good. Something like below,
from driver.FindElement(By.Id("btnLogin")).Click();
to driver.FindElement(By.Id("btnLogin")).Submit();
BTW, I have been tried all the answer in this post but not work for me.
add a comment |
In my case, my button's type is submit
not button
and I change the Click
to Sumbit
then every work good. Something like below,
from driver.FindElement(By.Id("btnLogin")).Click();
to driver.FindElement(By.Id("btnLogin")).Submit();
BTW, I have been tried all the answer in this post but not work for me.
In my case, my button's type is submit
not button
and I change the Click
to Sumbit
then every work good. Something like below,
from driver.FindElement(By.Id("btnLogin")).Click();
to driver.FindElement(By.Id("btnLogin")).Submit();
BTW, I have been tried all the answer in this post but not work for me.
answered Feb 1 '16 at 6:36
MichaelMaoMichaelMao
699828
699828
add a comment |
add a comment |
Got similar issue. Try to set more time in driver's constructor - add eg.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look likedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
add a comment |
Got similar issue. Try to set more time in driver's constructor - add eg.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look likedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
add a comment |
Got similar issue. Try to set more time in driver's constructor - add eg.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
Got similar issue. Try to set more time in driver's constructor - add eg.
var timespan = TimeSpan.FromMinutes(3);
var driver = new FirefoxDriver(binary, profile, timeSpan);
edited Mar 24 '17 at 15:47
ono2012
3,53712339
3,53712339
answered Mar 11 '14 at 11:11
bewubewu
85077
85077
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look likedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
add a comment |
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look likedriver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
Hi there bewu, would that be in the format like the below? driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));
– Nathan
Mar 11 '14 at 11:39
4
4
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:
driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
No, not this wait ImplicitlyWait is connected with finding elements. You need to change default(60sec) driver timeout, when it waits for request to be proceed(if I'm not wrong). Anyway you have to find a line where you set FF driver's constructor and add there more attributes or change the timeout. Something like:
driver = new FirefoxDriver(new FirefoxBinary(), new FirefoxProfile(path to your profile), TimeSpan.FromMinutes(3));
– bewu
Mar 11 '14 at 11:54
for ChromeDriver it would look like
driver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
for ChromeDriver it would look like
driver = new ChromeDriver(service, chromeDriverOptions, TimeSpan.FromMinutes(3));
– redwards510
Nov 4 '16 at 18:10
add a comment |
In my case, it's because I deleted the chrome update folder. After chrome reinstall, it's working fine.
add a comment |
In my case, it's because I deleted the chrome update folder. After chrome reinstall, it's working fine.
add a comment |
In my case, it's because I deleted the chrome update folder. After chrome reinstall, it's working fine.
In my case, it's because I deleted the chrome update folder. After chrome reinstall, it's working fine.
answered Nov 16 '18 at 6:11
gary.zhanggary.zhang
556
556
add a comment |
add a comment |
The problem is that the evaluation of Click()
times out on your build env.. you might want to dig into what happens on Click()
.
Also, try adding Retrys for the Click()
because occssionally the evaluations take longer time depending on network speeds, etc
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
add a comment |
The problem is that the evaluation of Click()
times out on your build env.. you might want to dig into what happens on Click()
.
Also, try adding Retrys for the Click()
because occssionally the evaluations take longer time depending on network speeds, etc
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
add a comment |
The problem is that the evaluation of Click()
times out on your build env.. you might want to dig into what happens on Click()
.
Also, try adding Retrys for the Click()
because occssionally the evaluations take longer time depending on network speeds, etc
The problem is that the evaluation of Click()
times out on your build env.. you might want to dig into what happens on Click()
.
Also, try adding Retrys for the Click()
because occssionally the evaluations take longer time depending on network speeds, etc
answered Mar 11 '14 at 10:21
bitbit
3,53011731
3,53011731
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
add a comment |
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Hi, The retry option wont work as the browser just locks up. Only stopping the test enables the browser to continue.
– Nathan
Mar 11 '14 at 10:57
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Can you manually try the Click() in the build env
– bit
Mar 11 '14 at 11:20
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
Hey, yes manually in the build env works
– Nathan
Mar 11 '14 at 12:06
add a comment |
I think this problem occurs when you try to access your web driver object after
1) a window has closed and you haven't yet switched to the parent
2) you switched to a window that wasn't quite ready and has been updated since you switched
waiting for the windowhandles.count
to be what you're expecting doesn't take into account the page content nor does document.ready. I'm still searching for a solution to this problem
add a comment |
I think this problem occurs when you try to access your web driver object after
1) a window has closed and you haven't yet switched to the parent
2) you switched to a window that wasn't quite ready and has been updated since you switched
waiting for the windowhandles.count
to be what you're expecting doesn't take into account the page content nor does document.ready. I'm still searching for a solution to this problem
add a comment |
I think this problem occurs when you try to access your web driver object after
1) a window has closed and you haven't yet switched to the parent
2) you switched to a window that wasn't quite ready and has been updated since you switched
waiting for the windowhandles.count
to be what you're expecting doesn't take into account the page content nor does document.ready. I'm still searching for a solution to this problem
I think this problem occurs when you try to access your web driver object after
1) a window has closed and you haven't yet switched to the parent
2) you switched to a window that wasn't quite ready and has been updated since you switched
waiting for the windowhandles.count
to be what you're expecting doesn't take into account the page content nor does document.ready. I'm still searching for a solution to this problem
edited Feb 29 '16 at 10:56
maazza
3,795124277
3,795124277
answered Feb 29 '16 at 10:17
ribboribbo
111
111
add a comment |
add a comment |
In my case I found this error happening in our teams build server. The tests worked on our local dev machines.
The problem was that the target website was not configured correctly on the build server, so it couldn't open the browser correctly.
We were using the chrome driver but I'm not sure that makes a difference.
add a comment |
In my case I found this error happening in our teams build server. The tests worked on our local dev machines.
The problem was that the target website was not configured correctly on the build server, so it couldn't open the browser correctly.
We were using the chrome driver but I'm not sure that makes a difference.
add a comment |
In my case I found this error happening in our teams build server. The tests worked on our local dev machines.
The problem was that the target website was not configured correctly on the build server, so it couldn't open the browser correctly.
We were using the chrome driver but I'm not sure that makes a difference.
In my case I found this error happening in our teams build server. The tests worked on our local dev machines.
The problem was that the target website was not configured correctly on the build server, so it couldn't open the browser correctly.
We were using the chrome driver but I'm not sure that makes a difference.
answered Nov 11 '16 at 15:43
Sean TomlinsSean Tomlins
185111
185111
add a comment |
add a comment |
changing the Selenium.WebDriver.ChromeDriver from 2.40.0 to 2.27.0 is ok for me
add a comment |
changing the Selenium.WebDriver.ChromeDriver from 2.40.0 to 2.27.0 is ok for me
add a comment |
changing the Selenium.WebDriver.ChromeDriver from 2.40.0 to 2.27.0 is ok for me
changing the Selenium.WebDriver.ChromeDriver from 2.40.0 to 2.27.0 is ok for me
answered Jun 19 '18 at 7:27
john liaojohn liao
110210
110210
add a comment |
add a comment |
For ChromDriver the below worked for me:
string chromeDriverDirectory = "C:\temp\2.37";
var options = new ChromeOptions();
options.AddArgument("-no-sandbox");
driver = new ChromeDriver(chromeDriverDirectory, options,
TimeSpan.FromMinutes(2));
Selenium version 3.11, ChromeDriver 2.37
add a comment |
For ChromDriver the below worked for me:
string chromeDriverDirectory = "C:\temp\2.37";
var options = new ChromeOptions();
options.AddArgument("-no-sandbox");
driver = new ChromeDriver(chromeDriverDirectory, options,
TimeSpan.FromMinutes(2));
Selenium version 3.11, ChromeDriver 2.37
add a comment |
For ChromDriver the below worked for me:
string chromeDriverDirectory = "C:\temp\2.37";
var options = new ChromeOptions();
options.AddArgument("-no-sandbox");
driver = new ChromeDriver(chromeDriverDirectory, options,
TimeSpan.FromMinutes(2));
Selenium version 3.11, ChromeDriver 2.37
For ChromDriver the below worked for me:
string chromeDriverDirectory = "C:\temp\2.37";
var options = new ChromeOptions();
options.AddArgument("-no-sandbox");
driver = new ChromeDriver(chromeDriverDirectory, options,
TimeSpan.FromMinutes(2));
Selenium version 3.11, ChromeDriver 2.37
answered Mar 19 '18 at 17:11
R2D2R2D2
112
112
add a comment |
add a comment |
protected by Community♦ May 18 '17 at 9:46
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
We had exactly the same issue in several independent projects using this setup and have still no workaround for this. Our best bet was to downgrade to older versions of the WebDriver and Firefox assemblies. We also do not know whether this behavior is caused by WebDriver or Firefox.
– Dio F
Mar 21 '14 at 10:27
I solved this problem, check out my answer here : stackoverflow.com/questions/15268255/…
– tanz
Nov 29 '16 at 0:59