Link to issue number:

Fixes #15164

Summary of the issue:

NVDA's support for Windows Defender Application Guard (WDAG) no longer workds as the requirement that the remote WDAG UIA tree be parented into the local tree under the main WDAG window is lon longer true. Thus it is impossible to find the local WDAG window and use this window handle for all WDAG NVDAObjects.
This means that NVA is essentially silent while focus is within a WDAG applcation.

Description of user facing changes

NVDA can again interact with applications such as Microsoft edge when run in Windows Defender Application Guard.

Description of development approach

• When trying to find the window handle for a WDAG UIA element, rather than walking up the ancestry, instead use the currently active window, if it is a WDAG host window and its for the same instance as the UIA element.
• Improve and refactor the part of UIA NVDAObject's findOverlayClasses method that deals with Chrome objects, to match on a UIA framework of 'Chrome', not just of a particular Chrome window class. Code needed to be also reordered so that more specific cases such as documents and lists where looked for first, before the more generic Chrome UIA classes.

Testing strategy:

• Opened Microsoft Edge.
• Opened a New Defender Application Guard window from the edge Settings button.
• Navigated to https://www.nvaccess.org/
• Ensured that NVDA reported focus while tabbing around the page.

Known issues with pull request:

• Browse mode is not available much of the time, due to IUIAutomationTextPattern::rangeFromChild failing on the document's text pattern when given an element within the page. This bug can be also reproduced with Narrator with Edge and WDAG. When outside of WDAG, this bug is not seen, thus it looks like some kind of marshalling bug for WDAG.
• As we can only locate the correct WDAG window if it is the active window, we will ignore UIA events from background WDAG windows. Generally we want this anyway, but it is worth noting.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.