Skip to content

fix(web): stop double paste in Chromium terminal - #70

Closed
macodev00 wants to merge 1 commit into
mainfrom
cursor/terminal-paste-dedupe-chromium-48b7
Closed

macodev00 wants to merge 1 commit into
mainfrom
cursor/terminal-paste-dedupe-chromium-48b7

Conversation

@macodev00

@macodev00 macodev00 commented Oct 1, 2026 •

Copy link
Copy Markdown
Owner

Fixes pingdotgg#13346

What Changed

The terminal paste shortcut races navigator.clipboard.readText() against the browser's native paste event. pasteShortcutToken only covered the native event landing first. When the clipboard read resolved first, the native paste that followed was also written to the PTY, so Chromium (Brave) inserted the text twice.

A read that wins records the text it delivered on the current paste gesture, and onPaste drops the one matching native paste. The gesture ends on that paste, the shortcut key's own keyup, a new paste shortcut, or blur. Other keys do not end it.

Why

This is the inverse ordering left open when pingdotgg#8457 was closed. The read exists for browsers whose paste shortcut never fires a paste event, so the native event cannot be cancelled. Recording the delivered text closes the read-first hole without giving up that fallback.

The record cannot live until the next keydown. Edit → Paste of the same string is an onPaste with no keydown, so it would be swallowed. It also cannot be cleared by unrelated keys: Chromium can deliver the native paste after other keys move, and clearing early lets the duplicate through. The shortcut's own keyup is after the keyboard paste (clipboard spec), so the duplicate is still dropped, and a later paste of the same text still lands. Blur ends the gesture when focus leaves before release.

Checklist

  • This PR is small and focused
  • I explained what changed and why
  • I included before/after screenshots for any UI changes (no visual change)
  • I included a video for animation/interaction changes (no motion change; event order is covered by the tests below)

Verification

cd apps/web && vp test run src/terminal/ghostty/surface.test.ts --project unit --reporter=verbose
 Test Files  1 passed (1)
      Tests  57 passed (57)
   Start at  06:37:18
   Duration  1.51s

The new cases all passed:

  • pastes once when the shortcut's clipboard read lands before the native paste
  • still drops the late native paste when other keys move mid-gesture
  • keeps a later menu paste once the shortcut that only the read served ends

tsc --noEmit in apps/web completed with no errors. vp fmt reported the two touched files already formatted.

Grok 4.7, Cursor cloud agent.

Open in Web Open in Cursor 

The paste shortcut races navigator.clipboard.readText() against the
browser's native paste event. The token only covered the native event
landing first; when the read resolved first, the following native paste
was sent again. Record the text the read delivered and drop the matching
native paste from that gesture.

The gesture ends on that paste, the shortcut key's own keyup, a new
paste shortcut, or blur. Unrelated keys do not end it, so a late native
paste is still dropped, and a later menu paste of the same text still lands.
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:M labels Oct 1, 2026
@macodev00

Copy link
Copy Markdown
Owner Author

Opened upstream.

@macodev00 macodev00 closed this Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Terminal paste lands twice in Chromium browsers (inverse of the #8457 race)

1 participant