Sign up
View stargazersSign up

Message link context menus do not receive focus with screen readers on Windows#10390

openedSep 6, 2026byAakj

What happened

Opening a message link's context menu in NVDA browse mode does not move focus to its options reliably.

Diagnosis

A link-focus event can arrive after the native desktop menu opens, leaving NVDA on the underlying link. Preserving Electron's keyboard invocation source helped an initial comparison but did not fix repeated openings in the app.

Steps to reproduce

  1. In the Windows desktop app, use NVDA browse mode to read to a message link.
  2. Press Applications or Shift+F10.
  3. The menu opens, but NVDA does not move to its options. Repeat with another link if the first attempt works.

Environment

T3 Code 0.0.39-nightly.20260906.1303, Windows 11, NVDA.

Evidence

Windows accessibility logging captured link focus after the native menu opened. The reporter confirmed that an in-page ARIA menu worked, then verified the integrated fix with T3's existing menu component on both web and file links.

Fix applied

#10391 uses the existing in-page menu component for message links. No changes to the installed app or NVDA settings.

Filed by Codex, GPT-6, following the T3 triage playbook.

JJulius MarmingeSep 6, 2026

Triage

Confirmed in current desktop source. This is a real accessibility bug, not a support/setup issue.

Message-link right-click already goes through a custom desktop menu (ChatMarkdown → showExternalLinkContextMenu → LocalApi.contextMenu.show → desktopBridge.showContextMenu). Applications / Shift+F10 fire that same contextmenu handler. The request then drops the invocation source:

  • DesktopBridge.showContextMenu / LocalApi.contextMenu.show only accept items + position (packages/contracts/src/ipc.ts).
  • IPC ContextMenuInput is { items, position? } (apps/desktop/src/ipc/methods/window.ts).
  • ElectronMenu.showContextMenu calls menu.popup() with window, optional x/y, and callback only (apps/desktop/src/electron/ElectronMenu.ts). There is no sourceType anywhere on this path.

Electron 43 already supports popup({ sourceType }) on Windows/Linux. When it is omitted, Chromium treats the menu as mouse-opened and does not select the first item, so NVDA browse mode never moves onto the options. That matches the isolated Electron comparison in the report.

The same contract is used by other desktop menus (file chips, sidebar, media). File chips already special-case clientX/Y === 0 for keyboard placement, but they still do not forward a source. This issue can stay scoped to message links; the fix belongs on the shared menu request.

Not upstream: Electron already exposes the API. T3 just never sends the keyboard source.

Related

Next step

Forward the keyboard source through the existing showContextMenu request and pass it to menu.popup(). Confirm with NVDA browse mode on the Windows desktop app (Applications / Shift+F10 on a message link). No further reproduction notes needed for the source gap.

Aakj9d ago
Synced from GitHub

Note

🤖 Claude Opus 5.5 responding on behalf of Andrew

Yes. On Nightly 0.1.2-nightly.20261021.3499 (Windows 11, NVDA), every menu fails on every opening: web links, file links, the thread actions button, and sidebar rows. The web build from main fails the same way.

With #18876 applied, web passes. Sending Windows desktop menus to that in-page menu makes all four pass in the desktop app too.

Once #18876 lands, I can open a PR for that change. It brings #18876's fix to every Windows desktop menu that uses it, not just links, and replaces #10391.