GNOME Bugzilla – Bug 779757
Wayland session: DnD from QT5 apps (running on xwayland) to GTK3 apps fail
Last modified: 2017-03-08 21:32:29 UTC
1. Run gtk3-demo (gtk3-demo --run=application_demo) 2. Run kate and open some text file 3. Select some text in kate, drop it onto gtk3-demo application demo window Actual result: gtk3-demo won't respond to pointer input until kate gets closed.
FWIW, bug #763246 turned that result into simply "text is not pasted"
An inconclusive analysis of what seems to happen: 1) mutter gets XFixesSelectionNotifyEvent saying that a window (kate's) claimed ownership of the XdndSelection selection, mutter takes this as a hint that X11 DnD is in progress. 2) DnD happens normally, mutter fetches mimetypes on XdndEnter, lets the drag dest choose an action. XdndDrop happens and mutter takes this as the hint to fetch selection contents on behalf of the wayland application, XConvertSelection is called for the selected mimetype 3) mutter gets an XSelectionEvent with prop = None. According to the manpage, this means: If no owner for the specified selection exists, the X server generates a SelectionNotify event to the requestor with property None. mutter however doesn't see any further XFixesSelectionNotifyEvents, which seems to indicate that kate is still the selection owner, and these same codepaths are used successfully in primary/clipboard selections.
Further findings. Debugging Xwayland it does seem like the event is not generated by X itself, the XConvertSelection() call results in a SelectionRequest event being send to the drag source as it would be expected. I can ATM only conclude that it's qt's equivalent to: https://git.gnome.org//browse/gtk+/tree/gtk/gtkselection.c#n2550 So it does seem like qt isn't convinced by mutter's impersonation of a DnD drag dest, If someone can point me to qt x11 code, I could see why this might happen.
Created attachment 347495 [details] [review] xwayland: Use timestamp from XdndPosition/Drop on XConvertSelection QT apps reject DnD if the timestamp received in the SelectionRequest event isn't the same it gave in XdndPosition/Drop client messages. Bookkeeping and using it in XConvertSelection makes it happy again.
Review of attachment 347495 [details] [review]: Mmh, OK.
Thanks! Pushed to master. Attachment 347495 [details] pushed as 38c5a16 - xwayland: Use timestamp from XdndPosition/Drop on XConvertSelection
Thanks for this super fast bug fix.