State of WinAppDriver

[kat-y]

Hi everyone, I (@kat-y) am the new Program Manager for WinAppDriver, so please feel free to direct your questions and concerns my way. I’d like to address the limbo and uncertainty around WinAppDriver – much of this is due to an internal transition of WinAppDriver ownership within the company, where it recently moved closer to the team that owns and supports our modern native Windows UI frameworks. This transition is complete, and WinAppDriver now lives with the same team that owns WinUI, WPF, React Native for Windows + macOS, and other products such as the Windows Terminal.

Presently, the team’s focus is on these aforementioned UI Frameworks. This means that, for the next ~6+ months, WinAppDriver development will remain paused. In the interim, we’ll be working in the repo with the community to construct an execution plan for when we do bring dev resources back to WinAppDriver.

Also, as I’ve been ramping up, I’ve taken notice at the many requests for WinAppDriver to be open-sourced. Open sourcing is a lot like any feature we’d consider adding to WinAppDriver: it takes resources to do it since we have to ensure the code is free of private APIs, represents modern OSS standards for Microsoft, has processes & license agreements properly reviewed by our legal team, etc. So ‘going open source’ is definitely on the list of things for the future of WinAppDriver, but this will also have to wait until we can apply more resources to the project in general. I’m looking forward to when we’ll be able to do that.

If you have any questions about what I wrote above, or about WinAppDriver in general, please reach out and ask. Thanks, I’m excited to have a chance to work with this great community!

Please note that a more recent update is #1150

[444ghost]

Hello,

I hope you do your best to bring back the dev resources to WinAppDriver asap. It seems like there's a memory-leak-related bug in WinAppDriver which I think it's very critical, and it has been around for almost 2 years but has not been knocked out.

https://github.com/microsoft/WinAppDriver/issues/991

Thanks.

[oren451]

Hi @kat-y! Joining other users hopes WAD returns to be under dev. A lot of product refinements need to go through to be the next thing, here some examples:

• Improve by far WAD finding element algorithms speed
• Many bugs, some critical to fix
• Create sessions over HWND of not top-level screens
• Extend the supported API
• Insert UI Automation API to WAD API (Instead using getAttribute('LegacyIAccessible.State')
• WinAppDriver need to be open-sourced
• Supporting also Java UI technologies
• Supporting ActiveX elements

Thanks and Good Luck!

[Daniwin82]

thanks for the update

[anunay1]

I have around 200 test cases implemented with WAD, but off late I am started observing after running for 3 to 4 hours the send keys API starts behaving weirdly, the API is not disposed properly even after driver.quit. its starts sending weird characters.

[anunay1]

Also it will be good to have logs with time stamp as the console logs are not very helpful.

[Wolfe1]

Thanks for the update, hope to see resources here soon!

I would suggest running through the open pull requests and merging the ones that still make sense to start cleaning up this github. The issues tab will be its own beast :worried:

[mattboroi]

@kat-y, looking for information regarding the publicly available Microsoft.WinAppDriver.Appium.WebDriver NuGet package.

• What are the similarities and differences between the Microsoft.WinAppDriver.Appium.WebDriver NuGet package and WinAppDriver released on GitHub?
• Are there plans for a WinAppDriver NuGet package that reflects the latest release on GitHub?

I did attempt to research open/closed GitHub issues and the Wiki/FAQ although I had not come across information regarding when or how to use the NuGet package verse installing the GitHub release.

Any information would be greatly appreciated and I'm very excited about all the recent activity behind this project and what it will produce for the community.

[varun210619]

Hi @kat-y Really good to see WinAppDriver is up and running. Hope there will be many enhancements to the tool in near future.

Could you please look into below issues-

https://github.com/microsoft/WinAppDriver/issues/507 I work in Nordic company and we work on Danish, Swedish, Finnish keyboards. When I send keys with value XXX-XX, winappdriver prints XXX+XX. Although there are many workarounds for typing correct required values, but please see if you can priotize it.

https://github.com/microsoft/WinAppDriver/issues/1357 My automation scripts contains many steps and sometimes I am required to use xpath. To validate any relative xpath, i have to execute whole script till the step where xpath is used. This consumes lot of time. Is it possible to create additional utility on top of winappdriver, where i just enter my xpath and tool highlights that element or provide an error. I am looking for utility similar console provided in chrome where i can enter xpath and css to validate in web application.

https://github.com/microsoft/WinAppDriver/issues/1378 I am finding winappdriver performance very slow. It takes a long time in step execution where xpath is used or where any table/grids appear. Even with tree views, it is very slow in execution.

https://github.com/microsoft/WinAppDriver/issues/1361 LegacyAccessible.Value attribute not working in winappdriver. No LegacyAccessible properties work with winappdriver. Sometimes, this is the only property to be used uniquely, but due to this issue, it becomes a bottleneck.

https://github.com/microsoft/WinAppDriver/issues/975 Fortunately i was able to get the developer settings enabled in my company, but it could be a show stopper or delay in getting these settings.

https://github.com/microsoft/WinAppDriver/issues/1103 You may close this one since WinAppDriver is up and alive :)

More enhancements but i have not opened any issues for these - I dont want to launch winappdriver.exe manually or even in the code. Is it possible that WindowsDriver itself deals with this whenever WinDowsDriver object is created.

[HenningL]

Highest priority for me would be the issue with processId not found. It seems for me that this is a general windows problem which might get compensated whith some internal knowledge. I recognized for some application (e.g. calc.exe) that even if i start the ".exe" programmatically and retrive the pid , when i insepect or watch tasklist, this pid doesnt even exist anywhere. The binding pid to session is the biggest hurdle to even start with WAD.

[liljohnak]

Would it be possible to implement scroll logic?

[rameshrc]

why do we need to install WinAppDriver.exe?

[riverar]

I think first and foremost, the README.md should reflect that new management has taken over and point to the new, supported feedback channels. I, and I'm sure other windev mvps, would love to help mop up too. (Feel free to reach out to the Windows Development alias; @DHowett @crutkas and others can help route.)

[fforjan]

In our case, we are still doing desktop application, engineering type, meaning we are testing that the application can test a workflow for 3 to 8 hours in a row. (Same as if you were testing Visual Studio) We have concern that Appium is having issues like memory leaks and will not be able to manage such use cases.

I would be also interested to see a white paper/blog post nowadays for usage of Appium in complex application like Visual Studio or Word and its integration into CI (CD?) workflows

[daniel-bsci]

We are looking into using WAD for our testing needs of WPF applications. But the production environment is heavily regulated and being forced to enable developer mode on system under test might be a deal breaker. Seems it should not be needed to automate WPF apps so removing that requirement is high on our list.

[liljohnak]

@daniel-bsci we are using it just fine with your specs. Also using chromedriver to test our chef embedded controls. Product does not ship with developer mode, just tested. Is there a benefit to your request?

[daniel-bsci]

@liljohnak I updated my post to clarify. Our devices are highly regulated, which includes changes to the OS. Not sure our QA would buy performing formal testing on a device with developer mode on when it won't be enabled in production.

[jayaprakashkottapalli]

Hi Kat-y, Congrats on your new role.

we are looking for a fix for an issue where running the appium for updating the value in the combobox/editbox available in a cell on windows application using infragistic wpf(19.1.20191.208) grid control takes lot of time locating the control within the cell.

Please could you let us know if we could get an resolution in the coming release: https://github.com/microsoft/WinAppDriver/issues/1052

[liljohnak]

Thought of another weird thing: .FindElementsByClassName() will return the parent element if the class name maches the search's class name. I do not think that this is the intent that anyone wants so would be nice to remove this behavior if possible. We added a check to to exclude the .Id from the list if it matches the parent.Id

[liljohnak]

We have WinAppDriver failing when the UI thread is locked in the App. We have our own wait that works around this, but maybe consider adding a capability of how long an acceptable ui lock should be.
Bottom of this comment: https://github.com/microsoft/WinAppDriver/issues/550#issuecomment-456976435

[leticiafer]

@liljohnak Is it possible to use WindowsDriver<WindowsElement> session = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), appCapabilities, TimeSpan.FromMinutes(10)); in java?

[Wolfe1]

@kat-y Any kind of roadmap or developments you can share?

[Purus]

Please remove the Developer Mode requirement. It's a real deal breaker for many organizations.

[DHowett]

Please remove the Developer Mode requirement. It's a real deal breaker for many organizations.

WinAppDriver is a tool that can be trivially used as a remote backdoor to script other applications. The absolute least we can do is require explicit system-level opt-in from an administrator to run it. Anything less, and we are shipping software signed and trusted by Microsoft that malware could drop on a machine undetected and undisturbed. Sorry, but no.

[riverar]

@DHowett That's a very unusual reply, given Microsoft OpenSSH and Visual Studio Remote Debugging tools, both with similar capabilities, don't have the same requirement. Instead of hastily dismissing the request, you should consider that Developer Mode has unintended side effects, like relaxing the need for elevated tokens to create symlinks. Tying WinAppDriver to Developer Mode doesn't quite make sense; I think the request is very appropriate.

[daniel-bsci]

@riverar I agree completely; use other mechanisms to ensure security other than forcing users to put the entire system under test in a less secure state (developer mode). It's not like it's a backdoor to the system; you still need administrator privileges to listen to anything other than local requests.

[specificJyurkiw]

WinAppDriver is a tool that can be trivially used as a remote backdoor to script other applications. The absolute least we can do is require explicit system-level opt-in from an administrator to run it. Anything less, and we are shipping software signed and trusted by Microsoft that malware could drop on a machine undetected and undisturbed. Sorry, but no.

How about some kind of windows container that sandboxes the driver? Would be cool if it could also be used to offer a kind of "effectively headless"-mode since it would basically be a VM anyway. Could also allow us to run tests in parallel on a single computer by running multiple containers so long as they all have their own virtual mice and keyboards.

[specificJyurkiw]

@kat-y Got any updates on WAD development? As far as I can tell it is the ONLY way to automate native windows application testing as the only alternative offered by Microsoft (Coded UI tests) were pulled from Visual Studio in 2019 in favor of this solution, which was then also basically abandoned.

Automation IS how companies and private individuals are testing applications now. And Microsoft is about 7 years behind and getting farther.

I know you can only do so much. Where else should we be making noise to get the right eyes on this problem?

[jlipps]

Hi @kat-y thanks for this update. Glad to hear things are picking up again! Speaking for the Appium maintainers, would it be feasible to have someone from your team represent WAD in our Appium contributor chat group? That way we can communicate easily and make sure changes on both sides maintain compatibility.

[pradeipp]

Hi @kat-y @DHowett, any updates on when we might get a new release? anywhere in 2021 Q2, Q3?

[liljohnak]

@kat-y this comment seems interesting. Maybe merits a doc update? https://github.com/microsoft/WinAppDriver/issues/1464#issuecomment-792452356