WinAppDriver is not updating the default timeout as set by driver.Manage().Timeouts().ImplicitlyWait()

[dhapolapankaj]

Team,

First of all, I am so excited to work on the WinAppDriver. The best part I liked here is, I can leverage the power of XPath to locate the desktop elements.
Let me be honest here, you guyz are doing an excellent job.
I never visualized I can treat the Windows Environment in XML format. (basically I exported driver.PageSource)
I see only one major drawback here is the Speed of WinAppDriver to fine elements.

OK, the main Issue here.
The code to set the default timeout for WinAppDriver isn't working.

I tried setting the default time out to 300 seconds, but it isn't working
driver.Manage().Timeouts().ImplicitlyWait(300);

The Exception I received while searching a particular elements is timed out after 60 second

Attaching screenshot.

Please let me know If I'm doing something incorrect.

[RafalSkorka]

You should rather do
driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(300);
otherwise you are setting ticks and not seconds.

[dhapolapankaj]

Hey Rafal,

I an unable to find ImplicitWait property.
Can you please share any link to MSDN Classes where I can find this property?

Regards
PD

[RafalSkorka]

see here: https://seleniumhq.github.io/selenium/docs/api/dotnet/html/T_OpenQA_Selenium_ITimeouts.htm

[dhapolapankaj]

Strange, I am not able to use that Property.

[caulfield2]

I too ran into the same problem. I posted my issue here #192 but apparently it fell on deaf ears. My workaround to this was speeding up the search process by "nesting" my search for certain elements. This allowed me to narrow down what area of my app the driver was searching and locate the desired element before WinAppDriver timed out. When trying to reference an element way down the hierarchy, it helped to first reference a higher level parent. See the code example below for further clarification. Hopefully this can speed up your search so WinAppDriver doesn't time out.

protected static WindowsElement Parent;
protected static WindowsElement Child;

Parent = driver.FindElementByName("parentName");
Child = (WindowsElement)Parent.FindElementByName("childName");
Child.Click();

[dhapolapankaj]

Thanks, I tried something on the same lines.
The biggest problem for me is the "app" value as "root" i.e. desktop
I need to have fewer applications open during findelement method.

I tried many possible combinations with XPath String, the least time that I was able to search for target element is 15-20 seconds, but for the automation that I am working on, need a time window of 5 seconds.

Let's see if we can find something more efficient.

[dhapolapankaj]

Hey @yodurr,
May I have your attention please?
Can you advise?
Regards
PD

[timotiusmargo]

Hi @dhapolapankaj,

Thanks for your patience. We have been focusing on preparing the v1.0-RC release that should address most of your concerns if not all.

The 60 seconds timeout you encountered above didn't come from WinAppDriver. Instead it is the default commandTimeout that is enforced by the client (Appium DotNet Driver and others). When using Appium DotNet Driver like the one we use in our samples and test, you can override the commandTimeout as follows:

```c#
// Launch Notepad Classic Windows Application
WindowsDriver NotepadSession;
DesiredCapabilities appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", NotepadAppId);
NotepadSession = new WindowsDriver(new Uri(AppDriverUrl), appCapabilities, TimeSpan.FromMinutes(5));

Notice the last argument passed into the WindowsDriver argument:
```c#
//
// Summary:
//     Initializes a new instance of the WindowsDriver class using the specified remote
//     address, desired capabilities, and command timeout.
//
// Parameters:
//   remoteAddress:
//     URI containing the address of the WebDriver remote server (e.g. http://127.0.0.1:4723/wd/hub).
//
//   desiredCapabilities:
//     An OpenQA.Selenium.Remote.DesiredCapabilities object containing the desired capabilities.
//
//   commandTimeout:
//     The maximum amount of time to wait for each command.
public WindowsDriver(Uri remoteAddress, DesiredCapabilities desiredCapabilities, TimeSpan commandTimeout);

In terms of finding element, finding nested element should absolutely help reducing the time it takes to locate the target element. In addition, the latest v1.0-RC release should now have a faster element finding turnaround. Specifically to your scenario, you can also create a new session from a top level window. Using this new feature, you no longer need to have fewer application on desktop once you established your session. Could you please give it a try?

It now takes less than 1 second from the moment the application window is open for the session (driver) to be ready.

[dhapolapankaj]

Hi @timotiusmargo

1. I have been focusing on RemoteWebDriver class for windows automation. Will try the appium desktop driver for the timeout command.

1. Okay, I will try some element search.

Thanks

[timotiusmargo]

Sounds good. FYI RemoteWebDriver also has a constructor that takes the commandTimeout as follows:

c# // // Summary: // Initializes a new instance of the OpenQA.Selenium.Remote.RemoteWebDriver class // using the specified remote address, desired capabilities, and command timeout. // // Parameters: // remoteAddress: // URI containing the address of the WebDriver remote server (e.g. http://127.0.0.1:4444/wd/hub). // // desiredCapabilities: // An OpenQA.Selenium.ICapabilities object containing the desired capabilities of // the browser. // // commandTimeout: // The maximum amount of time to wait for each command. public RemoteWebDriver(Uri remoteAddress, ICapabilities desiredCapabilities, TimeSpan commandTimeout);

[dhapolapankaj]

Hi @timotiusmargo ,
I tried to set the default timeout by 300 seconds as mentioned above.
It isn't working.

RemoteWebDriver desktopSession = new RemoteWebDriver(new Uri("http://127.0.0.1:4723"), desktopCapabilities, TimeSpan.FromSeconds(300));

WebDriver give up hope to find the requested element in approx 60 seconds

[timotiusmargo]

Hi @dhapolapankaj,

This is interesting. Not sure what Selenium.WebDriver NuGet package is used in your project, but the v3.0.1 works fine for me. Below is a modified SetImplicitTimeout_FindElementNotFound that overrides the default 60 seconds commandTimeout with 150 seconds that seems to work consistently for me.

```c#
public void SetImplicitTimeout_FindElementNotFound()
{
OpenQA.Selenium.Remote.DesiredCapabilities appCapabilities = new OpenQA.Selenium.Remote.DesiredCapabilities();
appCapabilities.SetCapability("app", CommonTestSettings.AlarmClockAppId);
var session = new OpenQA.Selenium.Remote.RemoteWebDriver(new Uri(CommonTestSettings.WindowsApplicationDriverUrl), appCapabilities, TimeSpan.FromSeconds(150));
session.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(120));

try
{
    stopWatch.Restart();
    var element = session.FindElementByName("InvalidAccessibiliyId");
    Assert.Fail("Exception should have been thrown");
}
catch (InvalidOperationException exception)
{
    stopWatch.Stop();

    // The search should fail after the timeout period lapsed
    Assert.IsTrue(stopWatch.ElapsedMilliseconds >= 120000);
    Assert.AreEqual("An element could not be located on the page using the given search parameters.", exception.Message);
}

}
```

If you still encountering issues on commandTimeout, it would make sense to follow it up on the Selenium dot net project instead as they are the one implementing it.

[adubry75]

Excellent idea! This fixed my issue. My problem is that my WinForm has a DataGridView in it, and there are 90,000+ products listed. I think doing a FindElementByName from the root level was causing it to fall into that grid and searching all 90,000 rows (which is way more than 60 seconds; so it timed out). Now I first grab the SplitContainer pane, then grab the ToolStrip from that, then I grab my button from the toolstrip. MUCH faster! Thanks! :)

I too ran into the same problem. I posted my issue here #192 but apparently it fell on deaf ears. My workaround to this was speeding up the search process by "nesting" my search for certain elements. This allowed me to narrow down what area of my app the driver was searching and locate the desired element before WinAppDriver timed out. When trying to reference an element way down the hierarchy, it helped to first reference a higher level parent. See the code example below for further clarification. Hopefully this can speed up your search so WinAppDriver doesn't time out.

protected static WindowsElement Parent;
protected static WindowsElement Child;

Parent = driver.FindElementByName("parentName");
Child = (WindowsElement)Parent.FindElementByName("childName");
Child.Click();