Repository navigation
Report a clipboard write that fails both ways - #1091
Merged
Merged
Conversation
A copy that `navigator.clipboard.writeText` refuses and the `execCommand` fallback cannot rescue now opens a "Copy failed" dialog in the desktop and VS Code hosts. The dialog shows diagnostics for the attempt and asks the user to post them to #1090. The diagnostics are the activation state, the triggering event, time since the last trusted press and key, focus, and each fallback step. They never include the copied text. The failure has not reproduced in Chromium or Playwright WebKit, so field reports are the way to find it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deploying mouseterm with
|
| Latest commit: |
3a1ce20
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c6e8c9f2.mouseterm.pages.dev |
| Branch Preview URL: | https://copy-failures.mouseterm.pages.dev |
dormouse-bot
reviewed
Oct 9, 2026
dormouse-bot
left a comment
dormouse-bot
left a comment
Collaborator
There was a problem hiding this comment.
The issue link breaks in the VS Code host, which is one of the two hosts this dialog targets. getPlatformOrNull()?.openExternal detaches the method from its adapter, and VSCodeAdapter.openExternal reads this.vscode.postMessage(...). Clicking the link therefore throws a TypeError instead of opening #1090. The Tauri and fake adapters don't read this, which is why the link works in standalone and Storybook.
ExternalTextLink already provides this link: a text-link underline button that calls getPlatform().openExternal?.(href) on the adapter. The suggestions below switch the dialog to it. App always has a platform, so the <a> fallback for a null platform has no caller.
nedtwigg
requested a deployment
to
hosted-preview
October 9, 2026 16:03 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
Reading `openExternal` off the adapter detached it from `this`, so the VS Code adapter threw on click; ExternalTextLink calls it on the adapter. The issue URL gets its outbound-lint entries as a user-clicked link. The paste-control-characters canary seed is regenerated over clipboard.ts's new import. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dormouse-bot
approved these changes
Oct 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Copy actions, such as Copy
surface:Nin a terminal's right-click context, sometimes fail with "Could not copy to clipboard", and a retry usually works. We could not reproduce this, so this PR collects evidence from the field (#1090).In WebKit,
writeTextis refused when the click does not count as recent activation. The fallback,execCommand('copy'), then runs after the await and fails too.The failure did not reproduce in either engine:
writeTextonce activation has lapsed, so the test was meaningful.Change
lib/src/lib/clipboard-failure.tscaptures each write's state synchronously at the click or key that asked for it. It also notes the outcome of each fallback step. The report never includes the copied text.writeTextToClipboardpublishes a report when both paths fail. Callers can opt out withreportFailure: false; the dialog's own "Copy details" does, so a retry cannot replace the evidence on screen.ClipboardFailureDialogis mounted inApp, so it covers the desktop and VS Code hosts. It shows the details with instructions to post them to Copy to clipboard sometimes fails (collecting diagnostics) #1090, a Copy details button, and the failure count.docs/specs/mouse-and-clipboard.md§4.5. The word budget is ratcheted.Modals/ClipboardFailureDialog.Fixes nothing yet; it collects evidence for #1090.
🤖 Generated with Claude Code