Alt keyup is missed while a webview editor has focus, silently turning a tab's Close button into "Close Other Editors"

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.136.1 (commit a44adf7f53e00964ab890f9f8758a334f1fc15bc)
- OS Version: Windows_NT x64 10.0.26200

## Steps to reproduce

1. Open several editor tabs.
2. **Give focus to a webview-backed editor** (see Scope). This is required — the bug does not occur when a normal text editor has focus.
3. Focus a different application.
4. Hold Alt and press Tab repeatedly to cycle back to the VS Code window. Keep Alt held for roughly a second after the switcher lands on VS Code, then release it.
5. Without pressing any key, hover a tab's close button.
6. The button's glyph changes and the tooltip reads **"Close Others (Alt+Click)"**.
7. Clicking it closes every other editor.

Normal state — plain `×` close buttons:

After the Alt+Tab, with no key pressed — the glyph has changed and the tooltip offers Close Others:

Note that in the second image no modifier key is being held. The window simply still believes one is.

## Scope

The focused-editor type is the discriminator, confirmed by testing:

- Focus in a **normal text editor** — no repro. The Alt keyup is seen and the close button stays a plain Close.
- Focus in a **webview-backed editor** — reproduces every time.
- Confirmed with the **built-in Markdown preview** (open a `.md` file, Ctrl+K V, click into the preview pane), so this needs no extension. It was originally found with a third-party webview editor, and both behave identically.

A second window launched with `--disable-extensions`, containing only text editors, did not reproduce — consistent with the focused-editor type being the discriminator rather than any extension.

The likely mechanism: while focus is inside the webview's iframe, the Alt keyup is not propagated to the workbench's modifier tracking, so the workbench keeps believing Alt is held. Because nothing re-syncs modifier state when the window gains focus, the stale state then survives indefinitely.

The long Alt hold matters: the Alt keyup is delivered to the window switcher after VS Code has already taken focus, so VS Code sees the modifier as still held.

**The latched state is cleared only by keyboard input — never by a focus change.** With the window in this state, clicking away to another application via the taskbar and then clicking back leaves the close button still in Close Other Editors mode. Pressing any key clears it immediately. (This also makes it awkward to inspect: opening Developer Tools via Ctrl+Shift+I clears the state through the keypress itself. Inspecting requires freezing the UI first, e.g. `setTimeout(() => { debugger }, 5000)` from the console, then hovering during the delay.)

The persistence across a blur/focus cycle suggests the window's modifier state is never re-synced when it gains focus.

## Expected

Once Alt is physically released, VS Code should not treat it as held. The tab close button should be a plain **Close**.

## Actual

The close button remains in **Close Other Editors** mode for an arbitrary period after focus, with no indication other than a hover tooltip. A single click destroys the whole editor group except one tab.

## Why this is more than a cosmetic modifier glitch

The Alt-latch on Windows focus switches is long-standing and was previously harmless in the tab bar, because the close button had no alternate action. The affordance added in **1.134** ("Close other editors from a tab", #328975) gave it one, which turns a pre-existing, invisible platform condition into a destructive action:

- Closing one tab is among the highest-frequency mouse actions in the editor, and Alt+Tab is among the most common ways to return to the window. The two compose directly.
- There is no signal at click time. The changed glyph and tooltip only appear on hover, and closing a tab is muscle memory — nobody hovers and reads first.
- The outcome is hard to undo. **Reopen Closed Editor** is the only recourse, and only until the window is reloaded. For webview-backed tabs (chat/agent sessions, notebooks, custom editors) the loss is more disruptive than for text editors.
- There is no way to opt out of just this behaviour. The only workaround is `"workbench.editor.tabActionCloseVisibility": false`, which removes the close button entirely.

This was hit as an actual data-loss event: a set of long-running agent-session tabs was wiped by one click on a `×` after an Alt+Tab, on the same day the client moved onto 1.134.

## Possible mitigations

Any one of these would be sufficient:

1. Reset modifier state on window blur/focus, and only honour Alt if a keydown was received by the window *after* it gained focus. There is precedent: #241190 (Ctrl not registered right after an Alt+Tab focus switch) was fixed this way in the February 2025 milestone.
2. Require the modifier to be pressed while the pointer is already over the tab bar, rather than accepting an ambient modifier state.
3. Add a setting to disable the alternate close action.
4. Route the alternate action through the existing confirmation for closing multiple editors.

## Note on history

This was originally proposed in #193357 (Sept 2023) and closed as `*out-of-scope`; it shipped later via #328975. The latched-modifier case does not appear to have been considered in either thread.