Accessibility Regression: NVDA mouse tracking broken due to Chromium 142 update (Upstream Issue)

[lucascastrorp]

Type: Bug

Description Since the recent VS Code update bumped the internal Chromium version to 142 (from 138), the "Mouse Tracking" feature in the NVDA screen reader has stopped working completely within the editor.

This is a known regression in Chromium starting from version 140. It affects all Chromium-based applications. According to the NVDA issue tracker, this bug has been identified and fixed in Chromium 144 (currently in Canary), but versions between 140 and 143 remain broken.

Impact This is a significant accessibility blocker. Users who rely on NVDA mouse tracking to explore the UI or read code by hovering are currently unable to use this feature, severely hampering navigation and productivity.

Steps to Reproduce

Launch NVDA (ensure mouse tracking is enabled in NVDA settings).

Open VS Code (running on Chromium 142).

Move the mouse cursor over the editor text, sidebar, or any UI element.

Actual Behavior: NVDA stays silent and does not read the element under the mouse.

Expected Behavior: NVDA should read the element under the mouse cursor.

Root Cause & Evidence This is not an NVDA bug, but a Chromium regression introduced in v140.

NVDA Issue Reference: nvaccess/nvda#18707 and nvaccess/nvda#18996

Chromium Status: The issue comments confirm: "This has been fixed in chrome canary (144)."

Proposed Solution / Request Given that Chromium 144 is not yet stable, we kindly request the VS Code team to consider:

Rolling back the internal Chromium/Electron version to a build based on Chromium 138 (or any pre-140 version) where this feature was stable.

Alternatively, applying a specific patch if possible until Chromium 144 becomes the stable base for Electron/VS Code.

Environment Information

NVDA Version: 2025.3.1

VS Code version: Code - Insiders 1.107.0-insider (7ba6cc6, 2025-11-17T05:05:47.761Z)
OS version: Windows_NT x64 10.0.26100
Modes:
Remote OS version: Linux x64 6.8.12-8-pve

[meganrogge]

@deepak1556 what can we do here?

[deepak1556]

Thanks for sharing the upstream issue links, however I am not seeing a correlation to the affected versions.

Chromium issue https://issues.chromium.org/issues/440293932
CL fixing the issue https://chromium-review.googlesource.com/c/chromium/src/+/6973131, it landed first in 142.0.7425.0 behind a feature flag kAccessibilityHitTestPointCopy which is enabled by default
Our current insiders is based on chromium 142.0.7444.162 which contains the fix

The change that landed in 143 (canary at the time) was https://chromium-review.googlesource.com/c/chromium/src/+/6997416 which just removed the feature flag but that shouldn't matter as it was always enabled.

If you are referring to a different chromium issue, can you please provide a link to it and we can look into backporting the fix if its missing in our versions. Thanks!

[lucascastrorp]

@deepak1556, thanks for the detailed explanation regarding the Chromium versions.

However, I can confirm that the issue persists on my end with the latest VS Code Insiders build.

I noticed that the Chromium commit regarding version 143 states: "This CL lands in 143, and we won't port it back to 141 and 142."

Since version 142 still relies on the feature flag kAccessibilityHitTestPointCopy (and potentially the killswitch mechanism mentioning in the commit), is it possible that:

1. The flag is not actually enabled by default in the specific Electron build VS Code is using?
2. The "killswitch" mentioned in the Chromium CL is currently active in 142, suppressing the fix?

Is there a command-line argument I can use to force enable kAccessibilityHitTestPointCopy locally to verify if this is indeed a flag issue?

[lucascastrorp]

Update:

I went ahead and tested launching VS Code Insiders via the command line to force the feature flag as discussed:
code-insiders --enable-features=kAccessibilityHitTestPointCopy

Result: The issue persists. NVDA mouse tracking remains non-functional even with the flag explicitly enabled.

This strongly suggests that the fix included in Chromium 142 is indeed being suppressed (possibly by the killswitch mentioned in the Chromium CL) or is not correctly propagating to this Electron build.

For reference, here is the comparison of my environments:

WORKING (Stable):
VS Code: 1.106.1
Electron: 37.7.0
Chromium: 138.0.7204.251
Mouse tracking works perfectly.

BROKEN (Insiders):
VS Code: 1.107.20251119008-insider
Electron: 39.2.0
Chromium: 142.0.7444.162
Mouse tracking fails completely, regardless of the feature flag.

[deepak1556]

The flag is not actually enabled by default in the specific Electron build VS Code is using?

Just checked, it is enabled by default.

The "killswitch" mentioned in the Chromium CL is currently active in 142, suppressing the fix?

Its the opposite, the feature flag when disabled is meant to suppress the fix.

I went ahead and tested launching VS Code Insiders via the command line to force the feature flag as discussed:

The flag name passed in is not correct, the right value is AccessibilityHitTestPointCopy.

Looking closer at the linked issues, the CL was created to address mouse tracking of links which regressed when UIA feature got enabled by default in 141 https://chromium-review.googlesource.com/c/chromium/src/+/6818985

Just a quick check, what happens when you run with code-insiders --disable-features="AccessibilityHitTestPointCopy,UiaProvider"

I will do some testing on my end as well and report back here.