Repository navigation
Conversation
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Owner
|
@greptileai review |
leftos
force-pushed
the
fix/windows-ctrl-v-paste
branch
from
October 17, 2026 13:14
851f776 to
b5c3ddb
Compare
Contributor
Author
Local
WSL (Linux x86_64) at cbb9fd1: The |
Owner
|
@leftos Remove the draft status once the PR is ready to be looked at. Thanks! |
Contributor
Author
|
@penso will do, still working on it! |
The previous commit let a paste or a file drop take a tab back from another window, but what was pasted or dropped was still thrown away: a window whose frame does not match its size refuses input, and only typed keys were held for later. The first paste or drop in an idle window was lost, and the user had to repeat it. Keys, pastes, and drops now share one hold queue, so they are delivered in the order the user made them once the frame matches. A held paste keeps only the action and reads the clipboard when it is delivered, so no image is kept in memory and nothing is read on the UI thread. A file drop is held for the pane under the pointer, or for the drop point when no frame is shown, which is hit-tested once one arrives. Ctrl-V on a remote pane is held the same way. Held pastes and drops follow the rules of held keys: they are dropped with an error if focus moves first, cleared on reconnect, and capped at four per gap, past which they are refused with an error. A held send that fails now says how many held inputs it discarded. A held paste or drop that is refused, or one that starts a remote file copy whose paths arrive only once it completes, ends the batch: the input held after it is discarded with the count, so a held Enter never runs a command without what was pasted before it. A fifth paste or drop refused at the cap ends the batch the same way. A held paste delivered while a menu is open or a focus click is pending is refused with a reason, and on macOS a held paste always reads the clipboard in the background. A live paste or drop sends held input before itself.
Off Linux the Edit keys were cmd-x/c/v/a. GPUI parses cmd as the platform modifier, which on Windows is the Win key, and Windows keeps Win+V (clipboard history), Win+X, Win+C and Win+A for itself, so the app's paste could not be reached. Plain Ctrl+V went to the pane as ^V, and Ctrl+Shift+V is often taken system-wide by other apps. Windows now follows Linux's Ctrl scheme: the Edit keys are Ctrl+Shift+X/C/A, fields accept plain Ctrl, and Edit menu clicks replay Ctrl+Shift. In a pane, plain Ctrl+V is the app's paste while the clipboard holds text. With no text on the clipboard it keeps its terminal meaning: an SSH endpoint's image bridge takes a clipboard image, and a local pane still receives ^V so an agent can read the clipboard itself. Windows has no clipboard image reader of its own. The Ctrl+V decision is a pure function with the platform passed in, so its tests run on every OS; the key_down wiring needs a native check.
On Windows plain Ctrl+V is the app's paste only while the clipboard holds text. Without text it keeps its terminal meaning: an SSH or WSL endpoint's image bridge takes a clipboard image, now that the Windows client reads clipboard images and uploads them, and a local pane receives ^V so an agent can read the clipboard itself.
leftos
force-pushed
the
fix/windows-ctrl-v-paste
branch
from
October 17, 2026 19:12
b5c3ddb to
e200326
Compare
leftos
added a commit
to leftos/herdr-gpui
that referenced
this pull request
Oct 17, 2026
penso
added
bug
…l-frame # Conflicts: # crates/herdr-gpui/src/window/file_drop.rs # crates/herdr-gpui/src/window/pending_input.rs
The merge of upstream main brought tests that still read paste_files as a bool; it now returns Delivery, so they compare against Refused.
Since the metadata-update change on main, a newer snapshot that keeps the same focus and changes only metadata keeps input flowing, so the held-paste tests that opened their gap that way never saw input pause and timed out on every Unix CI job. The gap's snapshot now also republishes the host's key bindings, which still holds input until the matching surface arrives.
… fix/windows-ctrl-v-paste
This branch has not been deployed
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.
Stacked on #637: merge #637 first. This branch carries #637's commit (f81762f) under its own two, so until #637 merges the diff here shows both. Merged on its own, it would not build: its Ctrl+V calls #637's held-paste path.
Summary
On Windows, plain Ctrl+V in a pane went to the terminal as
^V, and the Edit menu labelled paste with Ctrl+Shift+V, which other apps often take system-wide.paste()→ fix: hold a paste or file drop until the window's frame returns #637'spaste_or_hold), so a Ctrl+V pressed while the window waits for its frame is held like any other paste and pastes the clipboard as it is when the frame returns.^Vreaches the pane so an agent can read the clipboard itself.actions::EDIT_KEYS). Cut, copy and select all stay Ctrl+Shift+X/C/A.macOS and Linux behaviour is unchanged.
Validation
On #637 at f81762f,
mainat 7c64479; run at e200326 (the same change as fb4d19fa, re-stacked onto #637's final commit without conflicts).check-commits(upstream/main..HEAD): passedformat-check,check-file-size,check-sorted,lintpassed;cargo test --workspacedefault and all features passed apart from 4 Credential Manager tests that need an interactive logon (they pass in one) and 4 timing tests that passed on re-run.window::pending_inputandwindow::input: 23 passed, 0 failed.cargo test --workspacefailed onlyorchestrator::tests::service::the_worker_shows_runs_another_application_writes, a load-timing test in code this PR does not touch, which passes alone.actions/tests/edit_keys.rs,window/input/tests/ctrl_v_paste.rs, andwindow/pending_input/tests/ctrl_v.rs(a Ctrl+V held for the frame pastes the clipboard once it returns).test-mockup-wait: the known Windows-only failure intest_wait.py; this PR touches nothing it covers.Screenshots
None captured. The only visible difference is the Edit menu's paste label on Windows (Ctrl+V).
Manual QA (native Windows, not yet done)
^V.