Command+V does not paste in the integrated browser on macOS #13897

Activity

1. juliusmarminge commented on Sep 27, 2026

   

   juliusmarminge

   on Sep 27, 2026

   Member

   More actions

   This is still broken on current nightlies, and it is not a reopen of #10659 or #11874.

   Those were closed after keyboard copy and the guest context menu were confirmed on builds that already contain #10621 and #10670. This report is 0.0.43-nightly.20260926.2318 (ea7d46ac), which includes both. Nothing on main since that commit touches preview keyboard handling. The #11874 follow-up confirmed Cmd+C and right-click on 0.0.42, and explicitly did not re-check paste.

   Ctrl+V failing on macOS is expected. isPreviewEditingShortcut only treats Cmd+V as paste (Meta, and not Control).

   Paste is still gated on guest focus, and that focus often is not the guest. Preview pages start with setIgnoreMenuShortcuts(true) so host accelerators do not fire. On keydown, Cmd+V clears that only when webContents.getFocusedWebContents() is the guest (syncMenuShortcuts in apps/desktop/src/preview/Manager.ts). Electron’s Edit → Paste role then inserts into whichever WebContents is focused. The context-menu path already documents the mismatch: native editing roles act on the focused contents, which may still be the host renderer while the click is inside the guest, so that path calls contents.focus() before Cut / Copy / Paste (apps/desktop/src/window/DesktopWindow.ts). The keyboard path never does. Automation also notes that WebContents.focus() is a no-op for webview guests. If the guest is not the focused WebContents, Cmd+V never becomes a guest paste: the menu shortcut stays suppressed, or the Edit menu pastes into the host, where the target is often not the field you are looking at.

   This is not the old clipboard-permission bug (#3738). Preview sessions already allow clipboard-read.

   To tell those two failures apart, please check the same field and reply with which of these insert the clipboard text:

   1. Edit → Paste
   2. Right-click → Paste
   3. Cmd+A, Cmd+C, and Cmd+X in that field
   4. Whether Cmd+V inserts into the composer instead of the page

   Also say what the field is (plain input, contenteditable, or a cross-origin iframe) and the page URL. If only the keyboard path fails, the fix is in syncMenuShortcuts, not clipboard permissions.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 27, 2026
3. jordanetzler commented on Sep 30, 2026

   

   jordanetzler

   on Sep 30, 2026

   More actions

   Same thing here on the stable build, 0.0.44. Command+V does nothing in the in-app browser. I click into a text field, paste, and nothing goes in.

   Apple Silicon MacBook Pro, macOS 26.4.1.

   Happy to grab logs or test a nightly if that helps.
4. AatmanAJ commented on Oct 3, 2026

   

   AatmanAJ

   on Oct 3, 2026

   Last edited by AatmanAJ

   More actions

   Can't reproduce this on current Nightly, so it looks fixed there.

   Setup: macOS 26.4, Apple Silicon (M5 Max), T3 Code Nightly 0.0.45-nightly.20261002.2595. It updated to 0.0.46-nightly.20261003.2632 (Electron 44.4.2) during testing. Integrated browser on google.com, caret in the search box (a plain input in the main frame), plain text on the clipboard.

   Your four checks:

   1. Edit → Paste: works
   2. Right-click → Paste: works
   3. Cmd+A, Cmd+C, Cmd+X in the field: all work. Text copied from the browser also pastes into the composer with Cmd+V.
   4. Cmd+V does not go to the composer. It pastes into the page's search box, as expected.

   Cmd+V itself pastes into the field every time.

   Screen recording attached below:
   https://github.com/user-attachments/assets/0858a05a-8005-4160-8c64-e620a3c54080

   I didn't find a change to syncMenuShortcuts or isPreviewEditingShortcut on main since this was filed. My older Alpha build (0.0.42) ships Electron 44.1.0 and the Nightly ships 44.4.2, so an Electron update may be what fixed it. Not tested: fields inside a cross-origin iframe, where getFocusedWebContents() may still not return the guest. @jordanetzler, could you try the latest Nightly?
5. tokyo-s commented on Oct 6, 2026

   

   tokyo-s

   on Oct 6, 2026

   Last edited by tokyo-s

   More actions

   Still happening for me on macOS: pasting passwords into login forms in the integrated browser doesn't work, so I have to type them by hand. This still needs a fix.

   The Nightly check above only covered Google's search box (a plain input in the main frame). Password fields on sign-in pages, which are often inside a cross-origin iframe, weren't tested, and that's where it still fails.
6. csh-helixbyte

   added a commit that references this issue on Oct 7, 2026

   fix(desktop): run unhandled browser editing shortcuts on the tab dire…

   ...

   1932b6c