Reputation: 66
For the last couple of days I've been struggling with IEDriverServer.exe and any version of IE. I have narrowed it down to any .Click()
commands that I make. When I use one, the test just seems to hang until it errors with a message like this:
"The HTTP request to the remote WebDriver server for URL http://localhost:2833/session/0cc60081-2142-427a-91b2-4563da3c3725/element/2c8403f6-7b06-4397-b2be-997a63ac3de1/click timed out after 60 seconds."
Also during this, the element I have tried to click completely hogs all the focus making clicking on anything else (even manually) difficult. If I manually hover over another element, it will flicker between the hovered element and the clicked element. I then enabled some logging and after a click event, all I see are the following:
T 2015-02-26 13:29:25:407 Browser.cpp(419) Entering Browser::Wait
D 2015-02-26 13:29:25:407 Browser.cpp(423) Navigate Events Completed.
T 2015-02-26 13:29:25:407 Browser.cpp(648) Entering Browser::GetActiveDialogWindowHandle
T 2015-02-26 13:29:25:407 Browser.cpp(192) Entering Browser::GetWindowHandle
D 2015-02-26 13:29:25:408 Browser.cpp(439) Browser busy property is true.
T 2015-02-26 13:29:25:408 IECommandExecutor.cpp(387) Entering IECommandExecutor::WaitThreadProc
T 2015-02-26 13:29:25:608 IECommandExecutor.cpp(207) Entering IECommandExecutor::OnWait
T 2015-02-26 13:29:25:608 IECommandExecutor.cpp(580) Entering IECommandExecutor::GetCurrentBrowser
T 2015-02-26 13:29:25:608 IECommandExecutor.cpp(586) Entering IECommandExecutor::GetManagedBrowser
repeated over the over again.
After some reading, I have tried a few things. Instead of using .Click()
, I changed it to use .SendKeys("\n")
. This helps pass the test, but seems like a very hacked solution and doesn't simulate an end user as fully as I would like.
I then started the browser with the option of EnableNativeEvents = false
. This stopped the focus hogging issue, but the .Click()
will still not actually work and neither will the .SendKeys("\n")
, both resulting in the same logs as before.
Clutching at straws, I also tried ignoring the zoom level with IgnoreZoomLevel = true
to no effect.
Is my only option to use the .SendKeys("\n")
?
Upvotes: 0
Views: 2319
Reputation: 71
This seems to be an old post, but thought of sharing the way I handled this issue. I ran into the exact same issue with every click(). I used the Javascript executory class and used the same object to click the element that is desired. And this worked like charm in my case. I came up with the following function:
protected void myClick (WebElement elementToClick)
{
String browser = ConfigManager.getWebBrowserName();
if ((browser.equalsIgnoreCase("ie")) | browser.equalsIgnoreCase("internet explorer")) {
JavascriptExecutor executor = (JavascriptExecutor)(JavascriptExecutor)driver;
executor.executeScript("arguments[0].click();",elementToClick);
}
else {
elementToClick.click();
}
}
Upvotes: 0
Reputation: 1352
I've struggled with very much the same problem and ended up with a hack that tries to click normally first and then uses .SendKeys("\n")
as a fallback. It looks like this (slightly simplified):
public static void ClickWithIeHackFailover(this IWebElement element)
{
try
{
element.Click();
}
catch (WebDriverException e)
{
if (e.Message != "Timed out waiting for page to load.")
{
element.SendKeys("\n");
}
}
}
It allows me to try the standard clicking first and then use SendKeys("\n")
as a fail over.
In order to get it working in all cases I needed to set the page load timeout like this when creating the driver:
driver.Manage().Timeouts().SetPageLoadTimeout(TimeSpan.FromSeconds(5));
This solves states where the browser won't return execution to Selenium because the page is busy which might be your case since you've got Browser busy property is true.
in your log.
I had this so question open while I came up with the hack: Why can't Selenium WebDriver find my element in a catch clause. It might give you more information.
Upvotes: 1