Bug 101353 - client to guest primary selection not working on Wayland (F25) with something already selected in the guest
Summary: client to guest primary selection not working on Wayland (F25) with something...
Status: RESOLVED NOTOURBUG
Alias: None
Product: Spice
Classification: Unclassified
Component: spice-gtk (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Spice Bug List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-08 14:46 UTC by David Jaša
Modified: 2017-11-29 10:53 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

Description David Jaša 2017-06-08 14:46:45 UTC 
client → guest primary selection not working on Wayland (F25) with something already selected in the guest

versions:
virt-viewer-5.0-1.fc25.x86_64
spice-gtk3-0.33-2.fc25.x86_64
copying/pasting with gnome-terminal, both g-t and v-v run on wayland (gnome-shell: alt-F2 → "lg" → Windows → select one → check if there is GType:MetaWindowWayland… or GType:MetaWindowX11… in first line)

steps to reproduce:
1. connect to the guest
2. select something in the guest
3. select something in the client
4. paste in the guest

actual results:
guest selection gets pasted

expected results:
client selection gets pasted

note:
until there is nothing selected in the guest, transferring primary selection from client to the guest works just fine
Comment 1 Pavel Grunt 2017-07-18 15:49:51 UTC 
Wayland as the guest or the client
Comment 2 David Jaša 2017-07-20 12:49:55 UTC 
F25 guest on top of el7 hypervisor works so it must have been client (F25 or F26).
Comment 3 Christophe Fergeau 2017-07-20 13:18:55 UTC 
I started looking into a similar bug on f25 client a while ago, I went as far as the GtkClipboard::owner-change signal not being emitted (or being emitted differently than on X11) when running on wayland. Did not have time to dig further :(
Comment 4 Jakub Janků 2017-10-30 19:53:30 UTC 
(In reply to Christophe Fergeau from comment #3)
> I started looking into a similar bug on f25 client a while ago, I went as
> far as the GtkClipboard::owner-change signal not being emitted (or being
> emitted differently than on X11) when running on wayland. Did not have time
> to dig further :(

That's true, on Wayland the owner-change signal is emitted once the window gains keyboard focus (see subsection "Selection" on https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing ).

I came across similar issue, but with normal clipboard selection (Ctrl+C/Ctrl+V). Primary selection seems to work fine, most of the time anyway.

Tested on my machine, there seem to be multiple problems regarding clipboard selection:
- owner-change is emitted twice, when we call gtk_clipboard_set_with_owner()
- clipboard_clear() is not called at all
- gtk_clipboard_set_with_owner() returns SpiceGtkSession, although the ownership of the clipboard was taken by another client (so it should return NULL). This causes the issue described by David.

I think this might be a bug in GTK, but further investigation is needed...

I came up with a quick temporary fix, see
https://github.com/jjanku/spice-gtk/commit/bf57fb2a31577f975855d60be407292f9ac5b594
Could you please give it a try?
Comment 5 Jakub Janků 2017-11-09 18:47:58 UTC 
Filed a bug in GTK:
https://bugzilla.gnome.org/show_bug.cgi?id=790031

Bug concerning double emission of "owner-change" signal has already been reported:
https://bugzilla.gnome.org/show_bug.cgi?id=775631
Comment 6 Christophe Fergeau 2017-11-29 10:53:38 UTC 
(In reply to Jakub Janků from comment #5)
> Filed a bug in GTK:
> https://bugzilla.gnome.org/show_bug.cgi?id=790031
> 

This bug is now fixed in master and the gtk-3-22 branch (thanks Jakub for the very useful test case!), and in my testing this was fixing that issue. I'd prefer that we don't add the workaround to spice-gtk, and just make sure the patch is backported to the gtk+ we are using. I'll close this bug, just reopen it if you disagree and think we need the workaround, or if the gtk+ fix is not enough.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.