[Bug]: HUD popovers stay open when a click lands outside the HUD window

[EtienneLescot]

Describe the bug

Esc does not close the HUD's language menu. The manual e2e checklist requires it:

Press Esc with the language menu open and confirm it closes without changing the locale.

Clicking outside the menu does not close it either. Clicking the language button again does, so the control itself works — only the dismiss paths fail.

The keystroke does reach the window: the HUD was confirmed as the foreground window (GetForegroundWindow → the packaged Openscreen.exe) at the moment Esc was sent, and the behavior reproduced twice.

Expected behavior

Esc closes the language menu and leaves the current locale unchanged.

To Reproduce

1. Start the app so the HUD is showing.
2. Click the language button (shows the current code, e.g. EN).
3. The locale menu opens.
4. Press Esc — the menu stays open.
5. Click anywhere outside the menu — it still stays open.
6. Click the language button again — now it closes.

Environment

• OS: Windows 11 (26200)
• Build: packaged Openscreen.exe 1.9.6, built from main @ 95e350e0 via npm run build:win
• Launched with OPENSCREEN_DISABLE_CONTENT_PROTECTION=1 so the HUD is visible in captures

Found during a computer-use pass over technical-documentation/testing/manual-e2e-checklist.md.

[EtienneLescot]

Re-tested on a packaged build with real OS input, and the report holds: Escape does not close the menu, while an outside click does.

Both listeners are registered in the same effect (LaunchWindow.tsx, window pointerdown + window keydown, guarded by isPopoverOpen), so the interesting part is that they do not behave the same way.

What was measured

Action	Result
Esc, 1st press	menu stays open
Esc, 2nd press	menu stays open
Left click inside the HUD window, outside the menu	menu closes

State captured at the moment of the keystroke, not before or after:

• foreground window = the HUD (GetForegroundWindow → the packaged Openscreen.exe, window title openscreen, i.e. the HUD and not the editor window, whose title is OpenScreen)
• HUD ex-style 0x00200000 — WS_EX_TRANSPARENT is not set, so the window is not click-through at that moment. That is the app working as designed: setHudMouseEventsEnabled(isPopoverOpen) deliberately makes the HUD input-opaque while a popover is open.
• the keystroke was real OS input (injected mouse/keyboard, not a renderer-dispatched event), and the click that opened the menu was the same

So the window was focused, interactive, and got the key. The menu did not close.

Method note

An earlier automated pass concluded the opposite — that Escape closes the menu whenever the HUD is foreground. That result did not reproduce here. Two things made the difference in this run, and they are worth repeating for anyone re-testing:

1. Atomic sequence. Hover → click → Esc → screenshot in a single uninterrupted batch. Splitting them across calls lets focus drift between the click and the key, which makes the result meaningless — an earlier attempt of mine had exactly that flaw.
2. Verify the input actually landed. Injected input can fail silently and still report success. Two different requested cursor positions returning the same coordinates is the tell. Checking WS_EX_TRANSPARENT on the HUD is a cheap, direct confirmation that a click reached the window rather than passing through it.

Consequence for the fix

The window.addEventListener("blur", closePopovers) change on claude/fix-435-hud-menu-dismiss closes the stuck-after-clicking-away state, which is real and worth having. But it leaves the Escape path byte-identical to main, so it does not address the symptom in this issue's title. The two want separate fixes.

The next diagnostic is the one to run first: with the menu open, evaluate document.hasFocus() in the HUD renderer and attach a temporary capture-phase keydown listener. That separates "the renderer never receives the key" from "it receives it and the handler is inert", and the answer decides which of the two the fix targets.

Environment: Windows 11 (26200), packaged Openscreen.exe 1.9.6, launched with OPENSCREEN_DISABLE_CONTENT_PROTECTION=1. LaunchWindow.tsx and HudControls.tsx on the tested build are byte-identical to origin/main.

[EtienneLescot]

Correction — my previous comment is wrong, and so is the premise of this issue as filed. Escape works.

A maintainer pressing Esc on a real keyboard closes the language menu. What I measured was an artifact of how my keystrokes were being delivered, not app behaviour. Retracting it with the evidence, because the earlier comment reads as a confirmed reproduction and it is not one.

What settled it

I attached a probe to the HUD renderer over the remote debugging port — observation only, no injected events — recording every keydown in capture, bubble and document-capture phases along with document.hasFocus(), then drove the HUD with the same synthetic input as before.

Key sent	Recorded by the renderer
a	yes — all three phases, isTrusted: true, hasFocus: true, target BUTTON
Escape, sent immediately after	nothing at all

So synthetic keys do reach the HUD; Escape specifically never arrives. It is swallowed upstream of the app. With the menu open and the HUD focused, the probe recorded only window.focus / window.blur around the click and no key event whatsoever.

That also explains the contradiction between my two passes: an earlier automated run drove Esc with keybd_event(VK_ESCAPE) and saw the menu close 4/4. That run was right. Mine was measuring a key that never left the harness.

What this means for the issue

The headline symptom — "Esc does not close the HUD language menu" — does not reproduce. The handleEscape path in LaunchWindow.tsx is correct and reachable, and needs no change.

What survives is narrower and was never about Escape: a click that lands beyond the HUD's native window leaves the popover open. That half is real and does not depend on synthetic input — a click outside the ~904×698 window produces no DOM pointerdown in the HUD renderer at all, so no renderer-side listener can see it, and nothing in the app closes popovers on window.blur (the renderer does receive that event; it is simply ignored).

So this issue should either be closed and reopened against that behaviour, or re-titled to it. I would suggest re-titling rather than closing, so the branch already pushed for it (claude/fix-435-hud-menu-dismiss, a window.addEventListener("blur", closePopovers)) keeps a home — that change is still worth having, and a reviewer already noted that it does not touch the Escape path, which is now exactly the right shape.

Method note, since this cost two wrong conclusions

"The window was foreground" and "the tool reported the key was pressed" are both worthless as evidence that a keystroke arrived. The only thing that settles it is asking the renderer what it received. A control key is what makes that reading conclusive — sending a alongside Escape is what separated "this key is swallowed" from "no key gets through".

[github-actions]

Fixed by #450 and merged into main.

This change is assigned to the Next Release release milestone and is not necessarily available in the latest downloadable desktop release yet. It is currently marked as status: pending release until a packaged release containing it is published.

[EtienneLescot]

Moved into v1.10.0 as part of the pre-release cut.