Support native mouse tracking in Chromium 142+ (UIA enabled by default)

[lucascastrorp]

Description
Starting with Chromium 142 (currently in VS Code Insiders), the UiaProvider feature is enabled by default. This enables native mouse tracking via UIA, fixing long-standing issues with Electron apps where mouse tracking was silent or required external add-ons.

However, NVDA does not currently opt-in to UIA for these windows by default. The current heuristic in UIAHandler specifically blocks UIA for the Chrome_RenderWidgetHostHWND window class unless the user manually forces the setting "Use UIA with Microsoft Edge..." to "Yes".

Steps to Reproduce:

1. Open an Electron app running Chromium 142+ (e.g., VS Code Insiders 1.107.0).
2. Ensure NVDA setting "Use UIA with Microsoft Edge..." is set to "Default" (which resolves to "Only when necessary").
3. Move the mouse over the editor code or UI elements.

Actual Behavior:
NVDA remains silent. It appears to fall back to the legacy IA2 path. Since Chromium 142 now prioritizes UiaProvider, the legacy path seems disconnected or incomplete for mouse hit-testing in this context.

Expected Behavior:
NVDA should detect that UIA is available and preferred for this Chromium version (or specifically when UiaProvider is active), and use it for object retrieval.

Technical Information:
The issue was analyzed by the VS Code team in issue microsoft/vscode#277895.
The root cause is located in source/UIAHandler/__init__.py, where Chrome_RenderWidgetHostHWND is treated as non-UIA by default:

nvda/source/UIAHandler/__init__.py

Lines 1256 to 1277 in 9fac0d8

	elif windowClass == "Chrome_RenderWidgetHostHWND":
	# Unless explicitly allowed, all Chromium implementations (including Edge) should not be UIA,
	# As their IA2 implementation is still better at the moment.
	# However, in cases where Chromium is running under another logon session,
	# the IAccessible2 implementation is unavailable.
	# 'brchrome' is part of HP SureClick, a chromium-based browser which runs webpages to run in separate
	# virtual machines - it supports UIA remoting but not IAccessible2 remoting.
	hasAccessToIA2 = (
	not appModule.isRunningUnderDifferentLogonSession and not appModule.appName == "brchrome"
	)
	if (
	AllowUiaInChromium.getConfig() == AllowUiaInChromium.NO
	# Disabling is only useful if we can inject in-process (and use our older code)
	or (
	canUseOlderInProcessApproach
	and hasAccessToIA2
	and AllowUiaInChromium.getConfig()
	!= AllowUiaInChromium.YES # Users can prefer to use UIA
	)
	):
	if isDebug:
	log.debug("_isUIAWindowHelper:Chromium window treated as non-UIA")

Specifically, the logic returns False for UIA usage unless AllowUiaInChromium.getConfig() == AllowUiaInChromium.YES.

System Info:
NVDA: 2025.3.1
App: VS Code Insiders (Chromium 142.0.7444.162)
OS: Windows 11

[isidorn]

@seanbudd @SaschaCowley this is a high priority regression surfacing in VS Code. Is it possible to fix this in the next release of NVDA?

[Emil-18]

@lucascastrorp, @isidorn IA2 is still much, much better in chromeium browsers than UIA. This issue isn't caused by IA2 anyway, it is caused by the fact that NVDA doesn't report the objects text when the objects textInfo is empty

[seanbudd]

We cannot move the default to UIA, as overall UIA has a worse implementation than the current IA2 implementation from Chromium in Browse mode. microsoft/vscode#277895 needs to be fixed for IA2 or the rest of UIA fixes need to be made so NVDA can switch

[hwf1324]

This issue isn't caused by IA2 anyway, it is caused by the fact that NVDA doesn't report the objects text when the objects textInfo is empty

@Emil-18, could you explain in more detail? I'm a bit unclear on what specific object this refers to?

[isidorn]

microsoft/vscode#277895 needs to be fixed for IA2 or the rest of UIA fixes need to be made so NVDA can switch

@seanbudd there are no plans for VS Code to fix that issue for IA2. What are the rest of UIA fixes that are needed so NVDA can switch?

@deepak1556 @meganrogge can correct me

[Emil-18]

@hwf1324 This refers to objects, such as the buttons in the formatting options toolbar, located beside the add a comment text box on github. If you move the navigator object to one of those buttons (make sure you are in object review mode, to make the review variable be an instance of the navigatorObjects TextInfo), open the python console with NVDA+control+z, and type the following
review.expand("textInfos.UNIT_STORY")
review.text
review.text will return an empty string. Hope this makes sence

[hwf1324]

This refers to objects, such as the buttons in the formatting options toolbar, located beside the add a comment text box on github. If you move the navigator object to one of those buttons (make sure you are in object review mode, to make the review variable be an instance of the navigatorObjects TextInfo), open the python console with NVDA+control+z, and type the following review.expand("textInfos.UNIT_STORY") review.text review.text will return an empty string. Hope this makes sence

@Emil-18, then I think you are referring to #11066, not this issue.

[seanbudd]

These are some (not all) of the known issues with Chromium's UIA implementation.
I found these from searching and the list may be incomplete.

• NVDA is not reading aria-current attributes in Chrome #19127
• NVDA is not reading aria-label strings properly for icon buttons in Chrome #18741
• UIA - Aria-label of toggle button with menu truncated to first letter #17665
• aria-label not announcing correctly for a button or link with only hidden content within it #17412
• Error when closing tabs via ctrl+w while using UIA in Edge Chromium #16435
• If NVDA uses UIA with Chromium based browsers, page scrolling is broken in Microsoft Edge #12135
• Backspace fails in some edit fields - UIA with Edge #12033
• reading separate list items with the mouse fails - UIA with Edge #12032
• NVDA doesn't announce texts referenced by multiple aria-labelledby properly on Edge browser #12001

Some concerning chromium issues as well:

• https://issues.chromium.org/issues/40820020
• https://issues.chromium.org/issues/40156648
• https://issues.chromium.org/issues/40662013
• https://issues.chromium.org/issues/379886423

[deepak1556]

Thanks @seanbudd for clarifying the state of UIA in chrome

IIUC, chromium still supports both IA2 and UIA paths side by side allowing accessibility clients to communicate in their preferred channel

@hwf1324 I haven't looked into your addon code to support mouse tracking for Electron apps under IA2, do you know if we are tripping on some condition when both IA2 and UIA paths are enabled side by side in the runtime ?

[hwf1324]

I haven't looked into your addon code to support mouse tracking for Electron apps under IA2,

You can refer to the discussion process in #17108 to understand the add-on prototype.

do you know if we are tripping on some condition when both IA2 and UIA paths are enabled side by side in the runtime ?

I use my add-on https://github.com/hwf1324/objectViewer to observe NVDA's object tree. By default, I observed that the Visual Studio Code - Insiders window NVDAObject is still an IA2 object, and then the object tree is truncated by an unknown object.

The window class name for this window is "Intermediate D3D Window"

[hwf1324]

While we can make the object tree accessible via UIA using the method in #17407 (comment), the mouse object unfortunately remains an IA2 object.

[hwf1324]

For Visual Studio Code - Insiders specifically, there's a simple solution in NVDA, but it's not general enough. If possible, I'd like to find a more general approach.

I suppose I could try redirecting objects as well, but I'm not familiar with UIA's COM calls.

CC: @michaelDCurran Perhaps you could advise me on how to plug NVDA's UIA objects through IUIAutomation.ElementFromPoint.

[hwf1324]

I found a simple way to temporarily mitigate this issue, but it's not the correct solution.

Updating Mouse Enhancements to v0.8.2 should temporarily alleviate this issue now.