Support UI Automation within a Windows Defender Application Guard process #7600
Summary of the issue:
On Windows 10 Enterprise, it is now possible to run Microsoft Edge within Windows Defender application Guard (WDAG). WDAG is a stripped-back version of Windows running in a special virtual machine that can securely isolate a process from the rest of the system.
Description of how this pull request fixes the issue:
These changes make NVDA function with Microsoft Edge in WDAG exactly the same way it would if Edge was running locally. The only difference being a noticeable drop in responsiveness.
On a windows 10 Enterprise machine:
Known issues with pull request:
If the name of the WDAG process ever changes (it is currently hvsirdpclient), not only will the WDAG process be inaccessible, but most importantly NVDA and or other parts of the system may experience hans or crashes due to the use of a nativeWindowHandle from a remote machine that is not valid locally. I have suggested to Microsoft that this is a major risk. Note though that without this PR the risk still remains the same.
Change log entry:
changes: * UIAHandler.getNearestWindowHandle: If this UIAElement's processID is for a local WDAG container process, jump up to its root (UIA className of "ApplicationFrameWindow") and use that element's windowHandle. Any windowHandle from UIAElements below this root are not valid on this machine. However before we check for the WDAG process, if the processID of the original element is 0, search up for the first valid one (Known WDAG bug) * UIAHandler.IsNativeUIAElement: If the processID is 0 (such as with UIAElements currently in WDAG), treat this UIAElement as having a native UIA implementation * UIA NVDAObject: don't get the processID of the UIAElement, instead fallback to getting it off its window. Currently a UIAElement in WDAG may have a processID of 0. This is a known bug. It should be the processID of the local container process.
…ag container process, then this element should be classed as being native. * Ensure IUIAutomationElement.cachedNativeWindowHandle is never used when it is not local -- needs to be rethought a bit.
…this allows screen hittesting, and allows us to remove some other code from UIAHandler.isNativeUIAElement.
Hi, For anyone commenting on this pull request, WDAG was announced in 2016, and introduced in Version 1709 (Fall Creators Update). Thus, tests should be done by other Windows Insiders running Windows 10 Enterprise or Education Version 1709 Preview. Thanks.
We can query the name of (a given) process. A WDAG process will have a name of "hvsirdpclient". There is no other way I know of to identify a process as a WDAG process apart from checking the name. Simply, I believe this UI Automation implementation is flawed as the nativeWindowHandle property does not expose a valid windowHandle as the spec promises.