fix(amicode): paste into the chat composer via the extension clipboard bridge - #17
Merged
Merged
Conversation
…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Problem
⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.
Root cause
The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:
navigator.clipboard/ native paste deliver no data.pasteevent to the frame — so hookingonPastenever fires.The fork already solved this for the onboarding profile inputs (
home-cards.tsx) with an extension clipboard bridge: the iframe posts aclipboard-request, the extension host readsvscode.env.clipboardand replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.Fix
readClipboardViaBridge()helper (clipboard-bridge.ts) — reuses the amicodepostMessageprotocol and self-gates to""outside the webview, so web/desktop are untouched.prompt-input.tsx), only when framed (inAmicode()),preventDefault, read via the bridge, and insert withaddPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.onPastebridge fallback (readClipboardTextinattachments.ts) covers context-menu paste.clipboard-requestresponder already exists and is gated to the visible panel.Testing
clipboard-bridge.test.ts— 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅tsgo -btypecheck ✅ ·oxlint0 errors ✅inAmicode()false) and the bridge helper resolves""immediately without posting.