fix(desktop): paste and other editing shortcuts work in every browser tab

[imqdee]

Problem

In the desktop app's browser panel, Cmd+V (and Cmd+C, Cmd+X, Cmd+A, Cmd+Z) does nothing in a tab whenever a newer browser tab or sign-in popup exists. Right-click → Paste still works. The app shortcuts forwarded from a browser page (for example reopen closed view) fail the same way.

The preview manager turns the native Edit menu shortcuts on for a page only when webContents.getFocusedWebContents() is that page. But Electron reports every <webview> guest of a focused window as focused (isFocused() follows the window), so getFocusedWebContents() returns one arbitrary guest, the newest one in practice. Every other tab then gets setIgnoreMenuShortcuts(true) on its editing keys. The context menu calls the paste role directly, so it never went through that check.

Change

Gate on whether this tab holds the keyboard: contents.isFocused() && contents.focusedFrame !== null. Window focus keeps the existing guard against input reaching an unfocused window. The focused frame picks the one tab the person is typing in. It also keeps an agent's keys out: since #18556, GuestInput sends an agent's keys to a tab without focus through sendInputEvent, which fires before-input-event there. Window focus alone would let those keys open the editing roles or forward an app shortcut.

Scope and approval

A very small, focused fix for an obvious bug, submitted without a prior issue. The browser panel already intends these shortcuts to work (#10621 added this gate to preserve them), and they fail only because of which tab Electron names. The change swaps one comparison in the two places that use it and restores the intended behavior, with no new behavior.

Verification

Reproduced on macOS with vp run dev:desktop, two browser tabs on the same local test page, and the Electron main process inspected over --inspect.

Before, with tab A (older, id 3) and tab B (newer, id 4) open and the window focused:

isFocused():               4:true  3:true  1(host):true
getFocusedWebContents():   4
Cmd+V in tab A:            setIgnoreMenuShortcuts(true)   -> paste dropped
Cmd+V in tab B:            setIgnoreMenuShortcuts(false)

With a single tab open, Cmd+V worked, which is why the bug looks intermittent.

After the fix, same setup:

getFocusedWebContents():   4
Cmd+V in tab B (4):        setIgnoreMenuShortcuts(false)
Cmd+V in tab A (3):        setIgnoreMenuShortcuts(false)
window blurred, tab A:     isFocused() false -> setIgnoreMenuShortcuts(true)

The Edit menu's paste role still runs paste() on the guest getFocusedWebContents() returns. With tab A focused, paste() on tab B inserted the clipboard into tab A's input, because Chromium sends a guest's paste to the window's focused frame. So once the gate is open, the text lands in the tab you typed in.

Also checked: keys sent over CDP (Input.dispatchKeyEvent through the tab's webContents.debugger, the route GuestInput uses while the tab holds focus) do not fire before-input-event at all. The other agent route, sendInputEvent into a tab without focus, does fire it, and the new test covers that case: an agent's Cmd+V and a forwarded chord sent to the background tab leave the menu shortcuts ignored and forward nothing.

Tests: vp test run src/preview/Manager.test.ts in apps/desktop passes (103 tests). The new test "keeps editing and forwarded shortcuts in whichever tab holds focus" fails on main and passes with the fix. Its agent-key half fails with a window-focus-only gate. Existing focus tests now drive isFocused() on the page instead of mocking getFocusedWebContents().

Not checked: a real OS keystroke end to end. The test machine could not post synthetic system key events, so the before/after above traces the gate with webContents.sendInputEvent, which fires the same before-input-event handler. The traces predate the focusedFrame half of the gate, whose behavior (null in a guest without focus) matches the Electron 44.4.5 harness in #18556 and what I observed in the dev app. Windows and Linux were not run.

Written with Claude Opus 5.5 in Claude Code.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-14T13:33:56.833351Z	df566c2	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[macroscopeapp]

Approvability

Verdict: Approved at df566c2

Macroscope's review found this PR approvable — This is a localized desktop bug fix that corrects focus handling for browser-tab editing and forwarded shortcuts, with targeted regression coverage. It does not introduce new capabilities, alter defaults, or affect sensitive or deployment-related code.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1632605a-dcd3-4a6f-ab48-6e3e2b76d8cc

📥 Commits

Reviewing files that changed from the base of the PR and between b3a3d8c and 0c73e4d.

📒 Files selected for processing: 2

• apps/desktop/src/preview/Manager.test.ts
• apps/desktop/src/preview/Manager.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

📝 Walkthrough

Preview shortcut handling now checks each guest WebContents for focus and a focused frame. Tests cover focused and unfocused guests, including multiple tabs in one host window.

Changes: Preview shortcut focus

Layer / File(s)	Summary
Guest focus checks apps/desktop/src/preview/Manager.ts, apps/desktop/src/preview/Manager.test.ts	Menu editing and forwarded shortcuts now require the guest to be focused and have a focused frame. Tests cover focused and unfocused guests, including a case where an older tab receives shortcuts while another guest is Electron’s arbitrary focused guest.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 0c73e

Shortcuts remain available in the guest holding focus while background guest input is excluded. No concrete merge-blocking behavior change was established.

Security architecture risk: 🔵 Low · up to 0c73e

The change is narrowly scoped and retains focus checks and existing command restrictions. No introduced security weakness was identified. Residual uncertainty concerns actual browser focus behavior rather than a demonstrated bypass.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The affected authority is native editing eligibility for the receiving guest or popup, and configured command delivery to the guest's existing host. The change does not add commands, destinations or input APIs.

Trust Boundaries and Controls

• observed — The added regression test models two guests in one focused window. It asserts that the older guest can use editing and forwarded shortcuts despite the global selection naming the newer guest, while input to the newer guest with no focused frame enables neither operation. These are mocked assertions, not independent runtime verification.

Resilience and Maintainability Implications

• inferred — Shortcut state starts disabled and is recomputed for each receiving guest's keyDown before forwarding, rather than accumulated across events. Focus loss or return is therefore evaluated on the next relevant event. Existing scope cleanup removes the guest callback, and failed listener installation closes the scope; the PR adds no asynchronous transition or recovery state.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title is concise, specific, and accurately describes the main fix: restoring paste and other editing shortcuts across browser tabs.
Description check		The description includes all required sections. It clearly explains the problem, the implementation, scope rationale, focused verification, observed results, limitations, and agent attribution. It doe…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[westline-jordan]

Physical-key reproduction on macOS (Apple silicon), tested October 16 with T3 Code Nightly 0.0.46-nightly.20261015.3176:

We opened two Browser tabs in order, A then B, and kept both open. Each showed a static HTML fixture with an ordinary readonly input containing orchard-614, selectable page text river-927, and editable textareas. There were no page scripts, clipboard APIs or custom copy/paste handlers. The operator used the mouse and physical Command keys.

Paste:

1. In newer tab B, select orchard-614 and right-click → Copy to establish a known clipboard value.
2. Click B's editable destination and press Cmd-V: orchard-614 appears.
3. Switch to older tab A, click its equivalent editable destination and press Cmd-V: nothing appears.
4. Right-click → Paste in A: orchard-614 appears.

Copy:

1. In A, right-click → Copy the page text river-927 to establish a baseline. Select the full input text orchard-614, press Cmd-C, then right-click → Paste into a destination: it pastes river-927, so Cmd-C did not update the clipboard.
2. Repeat the same procedure in B: it pastes orchard-614, so Cmd-C works there.
3. In A, establish orchard-614 as the baseline using right-click → Copy. Select ordinary page text river-927, press Cmd-C, then right-click → Paste: it still pastes orchard-614. Copy fails for normal page selection as well as input selection.

Right-click Copy/Paste worked in these controls. Clicking into the older tab's field did not restore its keyboard paste. Using right-click Paste to check keyboard Copy kept that result independent of the broken Cmd-V path.

This older-tab/newer-tab pattern matches the focus-gate problem addressed by this PR. These observations concern the visible desktop Browser pages; we did not separately verify a server-stream clipboard case, instrument live getFocusedWebContents()/focusedFrame values, or verify physical keystrokes on a patched build.

[Sa1mk0]

Confirmed on T3 Code Desktop 0.1.0 on macOS: Cmd+C/Cmd+V fail in an agent-opened browser tab, while Edit → Copy/Paste and the right-click menu work. Opening the same URL in a manually created browser tab restores keyboard copy/paste.

This matches the reported symptoms. We have not tested the proposed patch locally.