[BUG] Scanning UWP apps crashes since UIAutomation does not find any child elements about axe-windows HOT 8 CLOSED

@chingucoding
I think the most reliable way to solve this problem is probably not to call FindAll, but to use an IUIAutomationTreeWalker instead. How do you feel about giving that a try? If you want, I may be able to take a look in the coming days.

from axe-windows.

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from axe-windows.

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

from axe-windows.

Sure, I can give that a try. Can you point me to an example of that or the general idea of how this could work @DaveTryon ?

from axe-windows.

Hi, @chingucoding!

I opened WinUI 2 Gallery in AIWin, and there are 2 processes here. The topmost process (the child of the desktop) is named ApplicationFrameHost.exe. This process contains the system menu and the minimize/maximize/close buttons.

The second process, AppUIBasics.exe has a window that is a child of window owned by the ApplicationFrameHost.exe process. This the process that we're looking for. As pointed out earlier, we broke this in #676, where we limited the search to direct children of the desktop, rather than allowing the search to go arbitrarily deep.

The original code worked because it did a deep dive, effectively ignoring this note from the remarks section of the API documentation:

When searching for top-level windows on the desktop, be sure to specify TreeScope_Children in the scope parameter, not TreeScope_Descendants. A search through the entire subtree of the desktop could iterate through thousands of items and lead to a stack overflow.

So, to locate the process in question, we need to be able to do the following:

1. Go at at least 2 levels of depth
2. Look for elements that are not the first enumerated element
3. Still be reasonably performant

I wasn't able to locate sample code that does this, so I coded something up. I've created a sample PR of what this might look like. It works locally for both UWP and non-UWP apps. I'm pretty sure that it's leaking memory from not releasing the items in nonMatchingElements. Hopefully that should be fairly easy to sort out, though.

from axe-windows.

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

from axe-windows.

Awesome @DaveTryon , I'll take a look and create a PR then. Please assign this issue to me.

from axe-windows.

This was fixed in release 1.1.7

from axe-windows.