Description of problem: X selection buffers are not available to Qt applications running in Gnome cannot access any of this. This is an issue for applications still using the X buffers, like VIM. VIM buffers set X selection buffers but these are not available to Qt applications when running gnome-shell on Wayland. Version-Release number of selected component (if applicable): wayland-devel-1.17.0-2.fc31.x86_64 libwayland-server-1.17.0-2.fc31.x86_64 mutter-3.34.0-5.fc31.x86_64 libwayland-egl-1.17.0-2.fc31.x86_64 gnome-shell-3.34.0-3.fc31.x86_64 libwayland-client-1.17.0-2.fc31.x86_64 gnome-session-wayland-session-3.34.0-3.fc31.x86_64 gnome-shell-extension-background-logo-3.34.0-1.fc31.noarch gnome-shell-extension-common-3.34.0-2.fc31.noarch qutebrowser-1.8.1-1.fc31.noarch qt5-qtwayland-5.12.4-7.fc31.x86_64 wayland-protocols-devel-1.18-1.fc31.noarch xorg-x11-server-Xwayland-1.20.5-7.fc31.x86_64 libwayland-cursor-1.17.0-2.fc31.x86_64 falkon-3.1.0-2.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Run gnome with wayland 2. Install xsel and wl-clip to investigate the X and Wayland selection buffers respectively 3. Install qutebrowser and/or falkon 4. Open a terminal, open qutebrowser and/or falkon 5. In a terminal, set the different X selection buffers using `xsel -i` 6. Check contents of buffers 6a. wl-paste: shows copied text 6b. xsel -o -b: shows copied text 6c. xsel -o -p: shows second line (as expected) 7. Try pasting in falkon or qutebrowser: ctrl v or right click > paste (greyed out): nothing shown. Actual results: X selection buffers are not available to Qt applications in gnome-shell. This affects tools like Gvim that still use the X selection buffers. if one uses gedit, though, they are. Different issue there: https://bugzilla.redhat.com/show_bug.cgi?id=1758865 Expected results: They should? https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection Additional info: Not tested on KDE. On Ask Fedora, we ascertained that this wasn't an issue on F30, so this is an F31/gnome-3.34 related regression: https://ask.fedoraproject.org/t/yanking-from-vim-to-qt-applications-on-gnome/3534/22
Please note that when stuff is set to the right X buffer (-b: clipboard), it is available in Gedit.
Proposed as a Blocker for 31-final by Fedora user ankursinha using the blocker tracking app because: Sorry---caught this really late when using Gvim. Since Gvim still suffers X selection buffers, these are not available to Qt applications, but they do appear to available to native Gtk applications (tested with gedit and gnome-calendar). This worked in F30. This does not affect the default workstation application set (doesn't include any Qt applications?) but this is an issue that affects X/Wayland integration---not being able to copy/paste is core functionality. So possibly worth looking into before release?
Ankur, does this affect only primary/secondary selection buffer, or also the clipboard buffer (used by ctrl+c/ctrl+v in graphical apps)?
Also the CLIPBOARD buffer (-b option in xsel): $ echo "HAHA" | xsel -i -b (ins)[asinha@ankur-pc ~]$ wl-paste HAHA Try pasting in Qutebrowser next: nothing.
I'm really not at all sure whether it would, but I guess it's possible at least, so can you see if https://bodhi.fedoraproject.org/updates/FEDORA-2019-565a2a339d fixes this?
Actually, never mind, that change only touches spice so it can't fix this.
Discussed during the 2019-10-07 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as this does not clearly come under any existing criteria, but we may be open to considering a new one; however, we want to do more testing to identify the exact extent of the problem first. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-blocker-review.2019-10-07-16.02.txt
why is this filed against gnome-shell ? that seems a surprising choice for an issue that is reported as affecting specifically qt applications.
My reading was that it affects ANY Qt application, with those two only being given as examples, no? This should quite possibly be filed against mutter instead, considering there are other issues (including at least one accepted Freeze Exception, bug 1751646; see also bug 1759644) currently open regarding clipboard / drag & drop regressions in mutter 3.34.
(In reply to "FeRD" (Frank Dana) from comment #9) > My reading was that it affects ANY Qt application, with those two only being > given as examples, no? (Sorry, scratch that. I misread "specifically Qt applications" as "specific Qt applications".)
adding jgrulich and rdieter for a Qt perspective. I'd say as of now it's really not clear whose fault this is...
Can you try to update to Qt 5.12.5? If it makes any difference?
After investigation and discussion qtwayland developer, this appears to be a bug in Mutter. Problem is that Mutter advertises following mimetypes: [3516126,302] wl_data_offer("STRING") [3516126,310] wl_data_offer("UTF8_STRING") [3516126,316] wl_data_offer("TEXT") [3516126,321] wl_data_offer("INCR") [3516126,328] wl_data_offer("DELETE") [3516126,334] wl_data_offer("TARGETS") [3516126,355] wl_data_offer("MULTIPLE") [3516126,361] wl_data_offer("TIMESTAMP") Which are not valid mimetypes, they are X11 targets. Mutter should advertise "text/plain" or "text/plain;charset=utf-8" ideally.
(In reply to Jan Grulich from comment #12) > Can you try to update to Qt 5.12.5? If it makes any difference? Hi Jan, Just tested this out. The issue persists with 5.12.5 also Cheers,
I've debugged this issue and the paste issue only seems to affect QT apps that run under native Wayland (e.g. Calibre, Falkon). QT apps running under XWayland (e.g. Amarok, VLC) accept clipboard input just fine. Also, I'm only able to reproduce the issue if I populate the clipboard using "xsel -ib". If I populate the clipboard from *any* graphical app (it can be Wayland native or XWayland, it can be GTK3 or GTK2 or QT), pasting works OK in all cases, even in said QT Wayland native apps (Calibre, Falkon). The GUI apps must be doing something different compared to xsel when populating the clipboard. If anyone is able to reproduce this problem while copying a text from a GUI app, I'd interested in knowing which one. Overall, the impact seems to be extremely limited at the moment, at least according to my findings.
The upstream fix is at https://gitlab.gnome.org/GNOME/mutter/merge_requests/842
Will we be able to get this into F31?
Proposed as a Freeze Exception for 31-final by Fedora user jadahl using the blocker tracking app because: The X11 compatibility layer for clipboard and primary selection failed to handle more ancient (while still actively used) X11 practices; this results in failure to use said the clipboard and primary selection in a seemingly random fashion.
+1 FE, I guess, though honestly it's a bit borderline as it'd probably be fine as a 0-day update. But I guess just in case someone really wants to run gvim on the Workstation live or something.
+1 FE provided it's available ASAP and we have enough time to test it (i.e. not a day before go/no-go when all blockers are resolved).
Also -1 blocker due to very limited impact, per comment 15
-1 Blocker, +1 FE
-1 blocker, +1 FE
That's -4/+4, marking rejected blocker / accepted FE.
Upstream MR is merged now. A few other accepted blocker/FE bugs are in mutter, though, so we should probably round them all up into a single update.
FEDORA-2019-af6c89afe8 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af6c89afe8
gnome-shell-3.34.1-2.fc31, mutter-3.34.1-2.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-af6c89afe8
gnome-shell-3.34.1-2.fc31, mutter-3.34.1-2.fc31 does not fix the issue. Before, on gnome-shell-3.34.1-1.fc31, mutter-3.34.1-1.fc31, I was able to: echo "tt" | xsel -ib # and then paste the text to any GTK app or Qt X app On gnome-shell-3.34.1-2.fc31, mutter-3.34.1-2.fc31, I am not able to paste text from xsel to any Wayland application (gtk/wayland apps got broken too compared to previous situation, qt wayland wasn't fixed, gtk xwayland works fine).
I've just edited the update with a new mutter build that should fix that problem, can you test again? Thanks.
Yeah, it's all good with mutter-3.34.1-3.fc31 and gnome-shell-3.34.1-2.fc31. GTK and Qt, both Wayland and XWayland apps work just fine.
gnome-shell-3.34.1-2.fc31, mutter-3.34.1-3.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-af6c89afe8
I did update fedora 31 today but the issue of copy-paste between Qt apps is not working still Problem verified with this 2 apps: Freecad Google-Chrome
Jorge, you have to verify that your package versions match the update from comment 32. It's just in updates-testing repository (which has been disabled by default recently) and it might not be yet available on your closest mirror.
yes sorry preview update of yesterday hade disable the test-updating repo. It solved the issue Than you so much.
gnome-shell-3.34.1-2.fc31, mutter-3.34.1-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1761434 has been marked as a duplicate of this bug. ***
Clearing CommonBugs as we fixed this ahead of Final.
I've had copy/paste issues for the past few weeks, possibly related to this issue. As I'm not sure if it's the same bug (as it isn't Qt related, but affects Firefox, GNOME Terminal, VSCode, Signal, HexChat, etc.), I've opened a new one @ https://bugzilla.redhat.com/show_bug.cgi?id=1769236 with more details.