Description of problem:
My host system very frequently loses all clipboard contents whenever I have a virtual machine (through virt-manager) running (I don't need to be interacting with it, it can unfocused). I narrowed the problem to the following:
* Whenever you press ctrl+c or ctrl+x (i.e. write to the clipboard) on the host, there is a chance it gets wiped out (replaced with empty content). You might completely lose the content this way (if you do ctrl+x and the editor/app doesn't support "undo", the content is simply lost).
* This happens only with X11 host, not with Wayland host. Tested on F30 and F31 hosts.
* This happens only with F31 VM guest, not with F30 or F29.
* This happens extremely frequently with F31 GNOME guest, occasionally with F31 KDE guest, and never with F31 netinst environment (even though the clipboard integration does work in there). So it seems the desktop environment affects this problem somehow.
* Once you stop spice-vdagentd in the VM, the problem stops happening.
Of course this is a race condition, so some of my findings might not be true and happen differently on different hardware/software configuration.
I've created a script that periodically writes into system clipboard and exits once some external process changed it. I have attached the script. With GNOME VM, I can see the problem occurring almost immediately, mostly under 20 iterations:
Clipboard changed after 6 iterations!
Old text: A completely random string
With KDE VM, I can see the problem usually under 200 iterations. At least with GNOME, I don't even need to log in, just reaching GDM is enough. If the script cannot detect the issue for a longer time, interacting with the machine or restarting spice-vdagentd seems to increase the likelihood considerably.
Please figure out what changed in F31 VM guests compared to F30 guests and fix clipboard handling. Losing clipboard contents randomly is very inconvenient.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. use F30/F31 host with X11 session
2. boot F31 VM in virt-manager, ideally GNOME, fully updated (but F31 Live Beta works as well)
3. verify that spice-vdagentd is running and that host<->guest clipboard integration is working
4. run attached test_clipboard clip, it should report a problem almost immediately. Once it does, your system clipboard will be empty.
5. you can also try working as usual while having the VM running (window opened), eventually you'll end up with an empty clipboard after pressing ctrl+c or ctrl+x
Created attachment 1618646 [details]
This is a bash script useful to detect clipboard wipes.
Benjamin, you've already fixed bug 1750120, would you perhaps be able to look into this as well? Thanks a lot.
Sorry, I fear that this bug is really different. I don't think I am the right person to look into this.
I found out that when I have 2 VMs with F31 running, my clipboard is basically non-functional. My test script exits almost every time after 0-1 iterations. When I want to copy&paste something, I have to try e.g. 10 times before the clipboard is populated.
I think this might be an issue to discussing during blocker review meeting. If I have 1 VM running, it's hit or miss. When I have 2 VMs running, I'm almost unable to use basic functionality in apps , like ctrl+c&ctrl+v copying of files in Nautilus, text processing in text editors, creating bug reports in firefox (because I need to copy hyperlinks often) etc. The condition is that you have virt-manager running  with 1 (but preferably multiple) VMs with F31 guests (preferably GNOME), and you're using X11 session on the host.
Kamil, can you file an issue upstream at https://gitlab.freedesktop.org/spice/linux/vd_agent ? The upstream maintainer (Victor Toso) seems pretty active there but doesn't even have an account here, so I think we're more likely to get movement there.
There's an existing issue:
which looks sort of similar/related at least. That issue references this spice-gtk patch:
which looks like it has never been merged, so I guess you could try building spice-gtk with that patch and see if it helps?
The next/better version was:
Thanks! It seems those have not been merged yet either, right?
nope, I am not maintaining those components, and I am not affected by the bug (yet!), so I leave it to the spice team.
See also https://gitlab.freedesktop.org/spice/spice-gtk/issues/82 (which is probably the proper upsteam issue)
(In reply to Marc-Andre Lureau from comment #7)
> The next/better version was:
Marc-Andre, could you perhaps create a koji scratch build for testing? Or at least provide the patch in some more easily digestible form, e.g. as a PR against upstream gitlab instance, so that I can download the whole diff? Also, do those patched versions need to be installed on the host, on the guest, or both? Thanks.
Kamil, there's a patchwork for freedesktop. Here's all the relevant patches/series:
[Jan 16] First attempt to address #82, v1: https://patchwork.freedesktop.org/patch/277597/
[Jan 16] First attempt to address #82, v2: https://patchwork.freedesktop.org/patch/277609/
[Mar 21] "clipboard: skip release between grabs" series: https://patchwork.freedesktop.org/series/58353/#rev1
(rev2 seems to be a patchwork glitch)
[Mar 22] "Clipboard improvements" series for spice-gtk: https://patchwork.freedesktop.org/series/58418/#rev1
[Mar 22] "Clipboard improvements" series for spice-vdagent: https://patchwork.freedesktop.org/series/58418/#rev2
(note patchwork incorrectly thinks these are two revs of the same patch series, presumably because they have the same name)
I'm not sure what combinations of the above to try. I guess try just both of the March 22 series together first, then fiddle around with the others if that doesn't help.
BTW, I think you update spice-gtk on the *host* side and the agent on the *client* side, but can't hurt to update spice-gtk on both sides I guess.
This indeed is the same issue as #82, I assume that it's caused by commit 5c009c20 in mutter:
Previously, we saw issues on KDE with klipper which behaves the same as this new clipboard manager in mutter -- it takes clipboard ownership immediately once the original owner releases it.
(In reply to Adam Williamson from comment #12)
> [Mar 22] "Clipboard improvements" series for spice-gtk:
> [Mar 22] "Clipboard improvements" series for spice-vdagent:
None of these apply to the master branch of their projects. I tried to apply vdagent diff to the Fedora distgit tarball (version 0.19.0) and it applies well enough, but then fails to compile, because it seems to require some unreleased changes available only in master. I tried to figure out what commit are those patches based on and how to resolve conflicts when applying those damned mbox formats, but my beard is not long enough to help me succeed. This will need someone else to prepare the scratch builds.
I usually resolve conflicts by hand-editing the patches, but I may be nuts. :P
I rebased the series onto the current master, you can grab it here, branch "clipboard-race":
Discussed during the 2019-09-30 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as we think a bug of this nature could conceivably be a blocker under various criteria, but as this one only manifests when using an X11 session (not default in most cases) *and* running a virtual machine, we agreed it's slightly too limited in impact. Accepted as an FE as it can't be fixed for live images with an update.
(In reply to Jakub Janků from comment #17)
> I rebased the series onto the current master, you can grab it here, branch
Thanks a lot, Jakub. I built those projects and installed them on both host and guest. The clipboard problem seems to be entirely gone. Now I can have 2 VMs easily and the clipboard still works as expected.
I'm backporting all these patches to the packages. The linux-vd_agent branch has a *lot* of commits - I'm assuming all the not-obviously-related ones are needed for the clipboard ones to apply?
FEDORA-2019-565a2a339d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-565a2a339d
Oh, another question: do we need to send the agent fixes out for F29 and F30 as well?
spice-gtk-0.37-4.fc31, spice-protocol-0.14.0-3.fc31, spice-vdagent-0.19.0-4.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-565a2a339d
(In reply to Adam Williamson from comment #22)
> Oh, another question: do we need to send the agent fixes out for F29 and F30
> as well?
The users on F29 and F30 could benefit from this as well, but the patches haven't been even reviewed by the spice team properly yet.
Apart from that, some of them aren't related to this clipboard bug.
(In reply to Fedora Update System from comment #23)
> spice-gtk-0.37-4.fc31, spice-protocol-0.14.0-3.fc31,
> spice-vdagent-0.19.0-4.fc31 has been pushed to the Fedora 31 testing
I updated the F31 packages in my VM, but it doesn't fix the problem. I guess I'll need fixes for my F30 host as well, probably spice-gtk.
spice-gtk-0.37-4.fc31, spice-protocol-0.14.0-3.fc31, spice-vdagent-0.19.0-4.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
This is not fixed at least for F30 as a host. I'll try to test this with F31 host.
Adam, can you please submit an update for F30 as well? I guess the gtk part could be enough.
I was sort of hoping to wait for review on the patches before sending them out to stable releases (as Jakub implied in #c24). Jakub, any news on review?
(In reply to Fedora Update System from comment #26)
> spice-gtk-0.37-4.fc31, spice-protocol-0.14.0-3.fc31,
> spice-vdagent-0.19.0-4.fc31 has been pushed to the Fedora 31 stable
> repository. If problems still persist, please make note of it in this bug
I can confirm that this problem is fixed if the updated packages are installed on F31 host and F31 guest.
OK, so let's drop F31 blocker metadata and re-assign to F30, assuming that's OK for you.