GNOME Bugzilla – Bug 768887
Can't paste text copied in from QT5 Wayland clients
Last modified: 2021-07-05 13:52:52 UTC
GTK+ doesn't seem to be able to paste text copied from a QT5 client running with the Wayland QT backend. Steps to reproduce: 1. Open some gtk3 application using the Wayland backend where you can paste text (such as gedit or gtk3-demo -> entry) 2. Open some QT5 client using the Wayland backend (I used "./application -platform wayland" in /usr/lib64/qt5/examples/widgets/mainwindows/application on my system. 3. Enter some text in the QT5 client 4. Copy said text 5. Paste in the client opened in step 1 Result: Nothing is pasted Expected result: The copied text is pasted Note that pasting the text using weston-terminal works fine.
Did we make any progress on this ?
Tested on Arch running qt5 apps under Wayland: this problem is still present.
Same problem on Gnome 3.26.1, Arch linux.
QT5 implements version 1 of the wl_data_device_manager protocol interface, whereas mutter/gtk+ implement up to version 3 of this interface. There is indeed an interoperation bug between v1 and v3 (which is in mutter, so reassigning the bug there), but someone should file a bug to QT and tell them not to use outdated and fundamentally broken versions of the protocol.
Created attachment 362835 [details] [review] wayland: Allow interoperation between v1 drag source and v3 drag dest Since v1 of wl_data_device_manager does not have actions, explicitly assume a "copy" one from the drag source.
Created attachment 362836 [details] [review] wayland: Allow interoperability between v3 drag source and v1 drag dest Since v1 of wl_data_device_manager does not have actions, assume a "copy" one from the drag destination.
Review of attachment 362835 [details] [review]: lgtm.
Review of attachment 362836 [details] [review]: lgtm.
I just noticed thought that the original bug description said "paste". c&p seemed to work here at first glance, on a closer look it seems what is broken is pasting through the context menu. Apparently QT5 does always issue wl_data_offer_destroy() on wl_keyboard.leave (Despite the keyboard focus immediately going to the popup). Probably the wl_data_device.selection docs stating: The data_offer is valid until a new data_offer or NULL is received or until the client loses keyboard focus. The client must destroy the previous selection data_offer, if any, upon receiving this event. Must have mistaken them into thinking it's ok to destroy the offer on wl_keyboard.leave. So it seems now we have 2 bugs to file :).
It could easily be interpreted as that way I guess. What would be the point of keeping it around when not having any keyboard focus? Either way, after the keyboard focus has been transfered to the popup, we should send a new offer anyway right? Is QT not using that one correctly? (off topic: we should disassociate keyboard focus with offer availability, especially since touch devices might not have a keyboard)
problem persists in gnome 3.28.2 + Qt 5.11.
This bug is intermittent on Arch Linux running Gnome 3.34.2. I can paste text copied from notepadqq running natively on Wayland into my internet browser (Opera) running on Xwayland, but I can`t paste the same text into leafpad (gtk2) text editor also running on Xwayland.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.