fix(server): a site's Copy button in a streamed browser tab offers its text#32801

Problem

In a streamed (server-runtime) Browser tab, a site's own Copy button reports success but copies nothing you can paste. The page is told the copy worked, the text stays inside T3's headless Chrome, and your next paste uses whatever was on your clipboard before. I hit this copying an app's credentials from a developer portal into a request_secret card: seven pastes in a row saved old, unrelated text. Cmd+C and Edit > Copy already work (#26633). Site buttons were turned off on purpose in #19561.

Issue: #32034.

What changes for the user

After you click a site's Copy button, T3 shows "<site> wants to copy text" with a Copy button. Your clipboard changes only when you click it. If the copy then fails, T3 says "Could not copy the text" instead of closing silently. Mobile shows the same choice as an alert (Not now or Copy), with the same failure alert. Selecting text and pressing Cmd+C still copies straight away, as before.

In both shots the page logged "writeText resolved". Before, nothing else happens. After, the offer appears and the clipboard keeps its old text until you choose Copy.

How it works

1. Catch the copy without exposing anything to the page. The isolated-world recorder from #19561 now also keeps text a page copies within 5 seconds of a trusted primary-button click, stamped with the time it was made, in a buffer separate from the copy-key buffer. navigator.clipboard.writeText fires no copy event, so a small main-world init script wraps Clipboard.prototype.writeText and the DataTransfer and DataTransferItemList setters and reports the text as a CustomEvent. A data report counts only while the trusted copy or cut event is running and only for that event's own clipboardData (9ee800f). The script is installed with context.addInitScript, so it runs before page scripts in every frame and popup.
2. Read it only for the human's own click. On the controlling viewer's clean left press, the server notes when the press was sent and dispatches it straight away. After the matching release it reads at 0, 250, 1000, 2500 and 5000 ms, and stops at the first text, at any newer press, on any change of control, when the viewer leaves, or when the tab closes. Each read takes only a copy made from that press up to the moment the read started, so an older copy is dropped and a slow read never takes the next press's copy. This is the pattern #34204 set for copy keys.
3. Offer, never write. The server sends a new stream message, copyOffer { text, host }, where host is the origin of the frame that copied. Web, desktop and mobile show the offer, and only your click on Copy writes the clipboard. Web uses writeTextToClipboard, so this also works on plain-HTTP LAN connections, and both clients report a failed write.

The 5 seconds matches Chromium's transient user activation, the time a normal browser gives a clicked page to write the clipboard. Real Copy buttons often await work first; my test page awaits a permissions query before writing.

Why this does not let websites put text on your clipboard

#18259 and #19561 closed real holes. Each one stays closed:

• No page-callable helper and no user activation. #18259 was a Playwright exposeBinding whose reply gave every page user activation. Nothing here can be called by the page or replies to it. The recorder lives in an isolated world the page cannot see, and the main-world wrapper only dispatches an event. A test asserts the recorder is invisible to the page and that navigator.userActivation.hasBeenActive stays false after the server's reads.
• Only your own click counts. #19561 removed a window in which any viewer message (mouse moves, wheel, resize) let text through. An offer now needs the controlling viewer's clean left press and release. Mouse moves, wheel, keys, right and middle clicks, two-button chords, agent automation clicks, read-only viewers and synthetic element.click() produce nothing. A forged report event without a real click is ignored.
• A page never writes your clipboard by itself. Even after your click, the page's text only becomes an offer. Your clipboard changes when you click Copy in T3's own interface, which names the site that copied. Dismissing the offer leaves the clipboard untouched.
• No leaks between tabs. The headless browser's shared clipboard, which every tab and profile writes to, is never read. Text comes only from the recorder in the tab you clicked.
• Old clients stay safe. copyOffer is a new message type. Clients without this change ignore it, so a new server never makes an old client write page text.
• Copy keys are unchanged. Cmd+C/X and Edit > Copy/Cut keep the direct path #26633 verified, in a separate buffer, so the two paths cannot take each other's text.

Verification

On the current head 862b291, which merges main (including #34204) on top of the maintainer commits (9ee800f, the earlier merge of main, and 0fa45a3) and the failed-copy feedback commit (91bdf45):

ServerBrowser.copies.test.ts runs the real scripts in headless Chromium: writeText, delayed writeText, execCommand, custom copy and cut handlers (including an unrelated new DataTransfer() changed inside the handler), non-string writeText arguments and failed conversion, a same-origin iframe delegating to its parent, frames reporting their own host, a popup and a page that grab writeText before the button runs, and the negative cases above. It also pins the recorder's clock to check the time windows: a click's read leaves a copy made from its own start onwards and drops one made before the press, and each copy key takes only its own copy. Removing either rule fails that case. ServerBrowser.test.ts covers routing: only the controlling viewer gets offers, and chords and a release-and-retake of control cancel them. #34204's busy-frame test now also sends a left click while an embedded frame's read is stalled; it fails with the old wait before the press. The web browser test checks that the toast writes only on Copy, without the Clipboard API, and that a refused write shows "Could not copy the text" (this assertion fails without the feedback commit).

End to end. I ran a dev server from this branch and drove its web client from Playwright's Chromium, with a streamed Browser tab on a local test page:

• writeText button (awaits a permissions query first): the offer "127.0.0.1:47831 wants to copy text" appeared, the clipboard kept its earlier marker until I chose Copy, then held the site's text.
• execCommand button: same result.
• A left click on an empty part of the page: no offer for 6 seconds, clipboard unchanged.
• Select text and Cmd+C: copied directly, with no offer.
• On main, the same writeText click showed nothing and left the clipboard unchanged.
• On 862b291, a page whose embedded frame from another origin (with its own process) runs 3 seconds of script: a Copy click sent 300 ms into that work reached the page at 301 and 304 ms. With the old wait before the press put back, it reached the page at 3004 and 3002 ms. In both, the offer appeared about 2.8 s after the click, once the frame answered, and the clipboard kept its old text until Copy.

The no-mistakes test step repeated these live and added: dismissing keeps the clipboard; delayed copies and their expiry; frames and popups report the copying origin; right, middle, chorded and synthetic clicks, agent clicks and read-only viewers produce nothing; and a plain-HTTP viewer copies after consent through the execCommand fallback. For the feedback commit it drove a real Chromium permission denial and a refused fallback to the "Could not copy the text" toast, and showed the mobile alert in the iOS app on an isolated simulator. Maria also verified the change on Linux in a real dev environment (comment above).

Not checked: an Android device and the packaged Electron app. The desktop app renders streamed tabs with the same web component.

Cost per click: reading every frame's recorder took 0.56 ms median for a 1-frame page and 2.46 ms for 21 frames in Chromium. A click with no copy costs up to five reads over 5 seconds, and a new press cancels the rest. None of them runs before the click is sent.

Limits

• navigator.clipboard.write() with a ClipboardItem is not captured, because its text arrives later as a Blob. Selecting the text and pressing Cmd+C still works there.
• While an embedded frame in its own process is busy, the click reaches the page straight away, but the offer appears only once that frame answers the read. A copy key's clipboard update after #34204 waits the same way. There is no time limit per frame.
• Desktop-rendered tabs are unchanged. They already write the clipboard natively.

Review

The change went through no-mistakes. Its review found 11 gaps in the first version and fixed them: custom copy handlers, items.add, a stale copy overwriting a newer write, delegated iframe copies, frame host attribution, chorded clicks, a release-and-retake control race, scripts that cache writeText early, non-string writeText arguments, failed conversion, and plain-HTTP clipboard writes. The CodeRabbit comment about a silently failing Copy is addressed in 91bdf45. The merge of main in 862b291 resolves the conflict with #34204 by moving click reads after the press, as that PR asked, and went through no-mistakes again (review, test, document and lint found nothing).

Related: #32034, #34204, #34186, #26600, #26633, #19561, #18259.

Written by Claude Opus 5.5 using Claude Code in T3 Code. Review, test and CI fixes by the no-mistakes pipeline using GPT-6.1 Sol in Codex. Maintainer commits by Maria (maria-rcks) and Julius (juliusmarminge).

Issues

Closes #32034

🤖 Generated with Claude Code