Repository navigation
Wait for the client's clipboard item in e2e, not a MIME type - #65
Merged
Merged
Conversation
The text, binary and copied-files steps copy an item with wl-copy, start a client that offers its own item, and wait_type for a mime type before pasting. wl-copy 2.3.0 already offers that type (text/plain;charset=utf-8 for text, and the one --type names), so the wait returns at once. The probe offers its item only at decoded frame 4, so the paste can still read our own copy, and step 6 failed intermittently with "got: e2e-clip-in". Each step now polls the paste until it is the client's item: the text equals e2e-clip-out, the binary paste matches the client's bytes, and the URI list no longer names the copied sources. The binary step sent the same blob both ways, so its client to compositor check passed on a paste of our own copy. The client now sends separate random bytes. wait_type had no other callers and is removed.
This was referenced Oct 16, 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
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.
The text, binary and copied-files clipboard steps in
scripts/e2e.shcopy an item with wl-copy, start a client that offers its own item, then callwait_typefor a MIME type before pasting. wl-copy 2.3.0 already offers that type itself:text/plain;charset=utf-8for plain text, and the type named by--typefor the other two. Sowait_typereturns at once, while the probe offers its item only at decoded frame 4, and the paste can still read wl-copy's selection. Step 6 failed intermittently with "client->compositor clipboard (got: e2e-clip-in)": 3 of 8 runs on this machine, on branches that do not touch that path. The binary step also sent the same bytes in both directions, so its client-to-compositor comparison passed even when the paste read the step's own copy.Each step now polls the paste until it holds the client's item: the text equals
e2e-clip-out, the binary paste matches the client's bytes, and the URI list no longer names the copied sources. The binary step sends separate random bytes from the client.wait_typehad no other callers and is removed.Validation:
bash -n scripts/e2e.sh: passes.scripts/e2e.sh: three runs in a row (nested Hyprland, AMD Radeon 840M, wl-clipboard 2.3.0) passed every step, including text clipboard (6), binary clipboard (8) and copied files (9).Found while validating #63. #47 also reworks these waits, so if it lands first this one can close.
Opus 5.5 high, on behalf of TechLuddite.
Implemented with Claude Opus 5.5 at high effort and checked with three full
scripts/e2e.shruns, then reviewed on 2026-10-19 by Claude, GPT-6.1 and Grok 4.7 at medium effort.