Link to issue number:

Fixes #11202
Fixes #11536
Partial fix for #11576

Summary of the issue:

NVDA can sometimes focus content in MS Edge / Chromium using UI automation, even though we have specifically disabled using UI Automation for Chrome in favor of IAccessible2.
This can happen either:

• when waking the computer / unlocking, and focus straight away goes to within a document in Edge such as in Nvwave, Outlook/UIA, sometimes Chromium Edge, NVDA freezes and needs to forcefully be restarted #11576
• When focus goes back to document content in Edge after closing a context menu such as in Edge Chromium: NVDA does not turn back to browse mode after closing the context menu #11202
• in Edge when a node in the document disappears and the web author does not first move focus somewhere else such as in Problems with the new Facebook interface, Edge 85 and NVDA #11536.

In all cases, the user may only notice that browseMode no longer works unless they tab or move focus once, but in the worse case, due to either bugs in Edge's UIA implementation or in NVDA's UIA rich text fetching code, NVDA may completely freeze. The freeze is partly why we disabled using UIA in Chromium in the first place.

In all cases, the following steps occur:

• The object (or Window) that had focus is destroyed, but NVDA still considers it the focused object as there has not been a new focus event yet.
• NVDA tries to locate the actual focus by asking the OS for the window with focus.
• This window apparently natively supports UI Automation. In this case it is a "Chrome_WidgetWin_1" window.
• In NVDAObjects.UIA.UIA.kwargsFromSuper: NVDA asks the OS for the UI Automation element with focus. In this case it gets back a link or other document content from Edge.
• NVDA however does not bother checking if this UIA element is a usable UIA element (I.e. it is not proxied, and we have not marked its window as being bad etc).

Like with similar code that asks the OS for an object at particular hittesting coordinates, it should ensure the UIA element it gets back is usable (UIAHandler.handler.isNativeUIAElement) and if it is not, it should return False, and thus Window NVDAObject will go on and try the focus according to MSAA.

Description of how this pull request fixes the issue:

Add the needed check to NVDAObjects.UIA.UIA.kwargsFromSuper

Testing performed:

• Logged into twitter.com in MS Edge 85 and focused a link. Put the computer to sleep and woke it up and unlocked the Windows session. Focus was restored to the link in Twitter, and it was confirmed that MSAA (not UIA) was used, by pressing NVDA+f1 and looking at the dev info.
• Logged into twitter.com with MS Edge 85 and focused a link in the document. Pressed the applications key to bring up the context menu. Pressed escape to close the context menu. Focus went back to the link, and it was confirmed that MSAA (not UIA) was used, by looking at the dev info with NVDA+f1.

Known issues with pull request:

None.

Change log entry:

Bug fixes:

• NVDA should no longer freeze when waking the computer and focus lands in a Microsoft Edge document. (Nvwave, Outlook/UIA, sometimes Chromium Edge, NVDA freezes and needs to forcefully be restarted #11576)
• It is no longer necessary to press tab or move focus after closing a context menu in MS Edge for browse mode to be functional again. (Edge Chromium: NVDA does not turn back to browse mode after closing the context menu #11202)