wl-copy sometimes does not copy, until copying something else into the clipboard manually

[Midar]

Sometimes, I pipe the output from my password generator into wl-copy. However, it happened now more than once than when pasting, I pasted something else - the old contents of the clipboard. No matter how often I call wl-copy then, it will not copy - until I manually copy something else (anything!) into the clipboard, then wl-copy suddenly works again.

zephyrus ~> dnf info wl-clipboard | grep Version\\\|Release                   1
Version      : 2.0.0
Release      : 4.fc34
zephyrus ~> dnf info mutter | grep Version\\\|Release   
Version      : 40.0
Release      : 1.fc34
Version      : 40.0
Release      : 2.fc34
Version      : 40.0
Release      : 2.fc34

The same happened on Fedora 33 and whatever version of mutter it ships with.

[bugaevc]

Can you please:

• Check with wl-paste (important!) that this is actually the case? That is, check that wl-copy is actually failing to copy, as opposed to wl-copy working fine and the app(s) you're pasting into not noticing and still pasting the old contents they have cached.
• Get me WAYLAND_DEBUG logs (e.g. WAYLAND_DEBUG=1 wl-copy --foreground I do not work)

[Midar]

Ok, seems that in this case, the terminal would paste the old contents, but wl-paste would paste the new. Only had one instance of this so far.

[Iss-in]

I am also seeing something like this, system clipboard is behaving weirdly. to replicate

copy an image on a firefox webpage

paste in a field, ie whatsapp,

on ist copy-paste attempt, instead of image, im seeing text like <meta http-equiv="content-type" content="text/html; charset=utf-8"><img alt="something" class="_something" src="something.jpg" style="max-height:700px">

then i copy the image again and, now pasting attempt is successful.

On nautilus also, sometimes first ctrl+c dosnt work at all.

on sway/arch currently

can't replicate with wl-copy/paste, so issue might not be related to them. anything similar on your side ?

[bugaevc]

@bool3max given that your comment is gone, I figure there was no bug, just --foreground working as expected?

@kushraj so what you're describing is just various clients misbehaving and does not involve wl-clipboard at all, correct?

You see, there are tricky details to implementing clipboards, Wayland clipboard included. I trust myself to have implemented things (mostly) correctly — which is why checking with wl-paste for what is actually in the clipboard is a good "ground truth" to compare others against.

[Iss-in]

yeah, I'm not sure what exactly is broken, will do a thorough check just to be sure. it was annoying me and I just wanted to be sure if it is a brand new general issue.

edit : apparently its clipman which is misbehaving, issue occurs when it runs it in background using wl-paste -t text --watch clipman store. guess i will report there

[bool3max]

@bool3max given that your comment is gone, I figure there was no bug, just --foreground working as expected?

Yes, I realized that that was expected behavior afterwards. Whoops. Though when I made the comment, wl-copy was refusing to copy anything from stdin (regardless of -f), but that got fixed after a reboot. Don't know whether I can bring back the comment somehow, for the sake of the logs, as I cannot reproduce the issue right now.

[bugaevc]

Don't know whether I can bring back the comment somehow, for the sake of the logs

For the sake of logs, the comment has been:

Same here, with 100% reproduction rate when using wl-copy from stdin.

echo something | wl-copy -f will hang forever, until something is manually copied into the primary clipboard, at which point pasting will result in the manually-copied contents being pasted.

On the other hand, not copying from stdin (e.g. wl-copy something) never fails.

[bool3max]

Yes, however after executing echo something | wl-copy -f pasting would result in no output. I had also edited the comment afterwards with logs, but I had deleted it since.

[bugaevc]

I had also edited the comment afterwards with logs

(Yeah, please don't do that. Even if you haven't deleted the comment, all of us who rely on notifications to know when a thread was updated with new info, or reading comments via email, will not see the updates. Case in point, @kushraj has amended their message above saying that it's related to Clipman, but you have probably missed that update.)

[kleshas]

I have this same issue. In thunar, pcmanfm, using right-mouse click copy context or ctrl-c the first time it doesn't copy anything. Re-copy and it's working again. Problem goes away when I killed the "wl-paste -t text --watch clipman store" process that is run in sway config (but then kitty paste doesn't work)

[bugaevc]

@kleshas Please attach WAYLAND_DEBUG logs (see above for the instructions).

[kleshas]

wl_paste.log

[bugaevc]

That looks like wl-copy succeeds in copying, but then something else — presumably, clipman — takes over the selection. If to you it looks like the copy failed, it would mean that clipman still provides the old contents instead of the new ones.

You could confirm that's the case by running wl-paste --watch cat and seeing if it outputs the new content, then the old contents again.

[kleshas]

wl-paste --watch cat displays the copied file, but as I said earlier, the paste option is greyed out, and ctrl-c doesn't do anything. So, no second line in the watch command.

[bugaevc]

Ah, so your problem is not with wl-copy, but with wl-paste --watch and clipman? Then I don't think I understand why you say it's the same issue — this issue report is about wl-copy, not clipman.

So if I understand you right, then this is the issue with clipman, and you should report it to them.

[kleshas]

OK, my bad.

[WammKD]

Just for awareness, I created an Issue at Clipman, in the hope this might get resolved: https://github.com/yory8/clipman/issues/86

[Soundtoxin]

I am having an issue where occasionally (such as in the morning these last two days in a row after leaving the PC on) one or both clipboards can't accept new content. Yesterday it was the primary selection. I could not seem to write to it at all (verified with wl-paste -p | less). In the end I think what finally fixed it was restarting qutebrowser and possibly copying something in it. In many of these cases the clipboard contents are frozen on the last thing qutebrowser copied, that or they're just stuck empty.

Right now I can copy to either clipboard from qutebrowser, but my scripts that use wl-copy and wl-paste aren't working, and I can't seem to copy to the regular clipboard from the foot terminal. I have tried killing any processes of wl-copy I see in htop and restarting qutebrowser a few times now but still only the primary selection seems to take new content, not the main clipboard.

I am not using clipman or the --watch argument anywhere.

I'm trying to dump the output of WAYLAND_DEBUG=1 wl-copy --foreground I do not work to a file but 1) it never ends and gives back my shell, 2) it doesn't seem to succeed in dumping anything to a file.

I've manually highlighted + middle clicked a few lines at a time from one shell to an open nvim window to get something. Hopefully I didn't miss anything important. Looks fairly repetitive anyway.

wl-copy-debug-logs_2022-11-14-085723.txt

I think all my Qt programs such as qutebrowser are running in xwayland at the moment in case that matters. foot is running in wayland. My script using wl-copy and wl-paste commands is of course non-graphical. Checked xwayland vs wayland with swaymsg -t get_tree | less and checking if a class or app_id is used for the particular program.

[YaLTeR]

@Soundtoxin Hmm, back when I used sway (1-2 years ago) there were some clipboard issues with Qt apps and with Xwayland. I don't know if they've been resolved since. Are you sure you aren't hitting one of the sway issues, could you try on GNOME or so?

[Soundtoxin]

I've used Sway for years and this issue only crops up occasionally. I suspect a Sway restart or reboot of my PC would temporarily fix it, and I don't know how to cause it intentionally, so I suspect testing with GNOME would not be especially useful.