nvda

6ec5ca33 - Support interacting with Microsoft Loop Components in Microsoft Office products (#13617)

Support interacting with Microsoft Loop Components in Microsoft Office products (#13617) Last year Microsoft announced Microsoft Loop – a new app which combines canvas with portable components that stay in sync and move freely across Microsoft 365 apps. Microsoft Loop: Flexible Canvas App | Microsoft 365. In short, these loop components can be added in emails, teams chats etc. These loop components use WebView2 controls is in visual hosting mode. When focusing one of these loop components, NVDA stays silent, does not track the focus, and provides no means of interacting with the embedded document. Steps to reproduce in Microsoft Powerpoint: 1. Launch PowerPoint 2. Launch NVDA 3. In PowerPoint, use keyboard shortcuts to navigate to Insert Tab (Alt N) 4. Insert either a PowerBI (PO) or Forms (F) add-in 5. Use NVDA to interact with the inserted components. I.e. tab through the content of the slide -- focus will also move through the inserted form. NVDA is ignoring events (including focus change events) in this embedded webview2 (Chromium) document as according to Windows the embedded document is never in the foreground, I.e. is not a descendant or, or owned by, the foreground window. When focus moves inside the Loop component, There is a Chrome_WidgetWin_0 window which gets focus, and this is correctly a descendant of the webview2 control window and in tern the _WwG document in Outlook and therefore a descendant of the foreground window. NVDA does see this at least. But, this Chrome_WidgetWin_0 window has no real content at all. The actual document content we are interested in is in its own Chrome_RenderWidgetHostHWND window, whose parent window is a Chrome_WidgetWin_1 top-level window. This top-level window is of course not a descendant of the foreground window, nor is it owned by the foreground or a descendant. Thus when NVDA sees events for controls inside this window, they get dropped as they seem to be in the background and not relevant to the user. Although Microsoft is unwilling to address the underlying issue by ensuring the Chromium document window is either owned by or a descendant of the foreground window, they have at least ensured that the ancestors of the Chromium document in the UIA tree does lead back to the embedding window in the Office document. Thus we can use UIA to detect this and allow the event through. Description of how this pull request fixes the issue: eventHandler.shouldAcceptEvent detects this specific scenario and allows the event through. Specifically: If the event's window is a background Chrome_RenderWidgetHostHWND, and the win32 focus is on a Chrome_WidgetWin_0 window, and the ancestor chain of the event window's UIA element leads back to a UIA element with a windowHandle matching the Chrome_WidgetWin_0 focused window, then the event is allowed through.