Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Most of the time when I'm trying to copy and paste, it simply doesn't work. If I try copying and pasting multiple times, it eventually does work. This seems to have started happening sometime within the past few weeks? Version-Release number of selected component (if applicable): Silverblue: 31.20191105.0 (2019-11-05T02:00:02Z) mutter-3.34.1-5.fc31.x86_64 gnome-shell-3.34.1-2.fc31.x86_64 libwayland-server-1.17.0-2.fc31.x86_64 xorg-x11-server-Xwayland-1.20.5-7.fc31.x86_64 How reproducible: It happens frequently, but if I copy and paste enough times, it eventually works. Steps to Reproduce: 1. Copy 2. Paste 3. ??? (It's a game of chance if it works as intended or not.) Actual results: Nothing is usually pasted. Sometimes the wrong content (old copy) is pasted. Other times, it works as expected. Expected results: Copy and paste should work, as expected, as it has for a few decades on Linux. Additional info: It's affecting Fedora 31 Workstation & Fedora 31 Silverblue. Both laptops are running GNOME on Wayland and this affects both Wayland and X11 apps on Intel chipsets. It affects non-Wayland X11 sessions on binary NVidia as well (so it's not Wayland-specific): https://twitter.com/snorp/status/1191853855740481536 I've seen this happen in: - Firefox (Wayland) - GNOME Terminal - HexChat Most-likely-related, but recently closed issues: https://bugzilla.redhat.com/show_bug.cgi?id=1758873 https://bugzilla.redhat.com/show_bug.cgi?id=1761434
I am affected with this bug as well. Copy paste works just sometimes, though it is unreliable. Workaround is to use the mouse buffer (middle mouse button).
I observe the same thing since I upgraded from F29 to F31. Ctrl+X removes the text, but Ctrl+V doesn't paste it. Usually the second time it works.
I experience this too since upgrading to Fedora 31. Copy and paste between certain programs is an issue. All packages are up to date on my system but the problem still persists.
Same problem here on wayland and fedora 31, but only sometimes, couldn't figure out when or with which programs it doesn't work.
I have the same problem. Select + Paste works with the mouse, but not with Shit+Insert or Ctl + v I am using Fedora 31 gnome-shell-3.34.4-2.fc31.x86_64 libwayland-client-1.17.0-2.fc31.x86_64 libwayland-cursor-1.17.0-2.fc31.x86_64 libwayland-egl-1.17.0-2.fc31.x86_64 libwayland-server-1.17.0-2.fc31.x86_64 mutter-3.34.4-2.fc31.x86_64 qt5-qtwayland-5.13.2-2.fc31.x86_64 xorg-x11-server-Xwayland-1.20.6-1.fc31.x86_64
I am having the same issue. Copy and Paste using mouse *does not* work among any apps Ctrl-C Ctrl-V does not work Ctrl-Shift-C Ctrl-Shift-V does not work gnome-shell-3.34.5-1.fc31.x86_64 mutter-3.34.5-1.fc31.x86_64 xorg11-server-Zwayland-1.20.6-1.fc31.x86_64 qt5-qtwayland-5.13.2-2.fc31.x86_64
Erasing clipit made the trick.
Created attachment 1680083 [details] Mutter - app1
Created attachment 1680084 [details] Mutter - app2
Created attachment 1680085 [details] Weston - app1
Created attachment 1680086 [details] Weston - app2
I can reproduce. I cannot copy from non-Qt applications to Qt applications, as well from a Qt application to another Qt application on Wayland. This works just fine on Weston or KDE Plasma session so I believe this is a Mutter issue. I attached outputs with WAYLAND_DEBUG enabled, where I ran Kate and KWrite on both Weston and Mutter and tried to copy text from one to the other and vice versa. What is weird that first copy/paste works, after that I'm unable to copy and paste any text.
I opened upstream bug for this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1194
I'm having this problem on fedora 32.
More observations but I cannot tell if these are all related. Here's my current configuration: # uname -r 5.7.7-200.fc32.x86_64 # env | grep -i sess DESKTOP_SESSION=plasma XDG_SESSION_DESKTOP=plasma XDG_SESSION_TYPE=x11 ... KDE_FULL_SESSION=true GDMSESSION=plasma # echo $XDG_SESSION_TYPE x11 # yum list installed ICAClient.x86_64 Installed Packages ICAClient.x86_64 20.04.0.21-0 @@commandline 1) When left double-clicking on a word in a Gnome terminal 3.28.2 in a Citrix ICA session (destination system is Gnome (gnome-shell 3.28.3-24.el7) on RHEL 7.5) for the first time, the word is selected and will stay selected. By running "xsel -po" (primary selection) and "xsel -bo" (clipboard selection) in a terminal on the host (=my desktop system running Fedora 32), I can prove that the word is indeed in both the primary and the clipboard selection. When left double-clicking on another word in that Gnome terminal in the ICA session, the word is selected but immediately afterwards, the selection disappears. When double-clicking on this or another word *again*, the word will again stay selected. From this point in time, I can double-click on any other word as often as I like but once I display either the primary selection or the clipboard selection in the terminal on the host, the disappearing word selection issue starts again. 2) Behavior in a Citrix ICA Windows session: I double-click on a word in Outlook to select it. Then, I press <ctrl>c to copy it to the clipboard. Then, I run "xsel -po" and "xsel -bo" on the host system. The correct word is displayed. I double-click on another word in Outlook to select that one. Then I press <ctrl>c to copy it to the clipboard. Then, I run "xsel -po" and "xsel -bo" on the host system. The *previous* word is displayed. I found that the only way to reliably avoid this behavior is to press <ctrl>c twice in the ICA Windows session. All this started to occur around year-end 2019. At that time, I had used Fedora (probably 30 or 31) with Gnome. So the issue is likely not related to the desktop environment. If necessary, I can try to reproduce the issue using any other desktop environment.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
As the issue exists on Fedora 32 as well, please change the version to 32. This behavior is not just annoying but also causing additional stress (I have to check the contents of the clipboard every time when copying/pasting from and my ICA client session), loss of time (as I have to use Google Docs as a clipboard in case the normal clipboard doesn't work), and maybe even loss of data (e.g. in case there is a "rm" command in the previous clipboard and it didn't get overridden by the current copy action).
Any update on this? I can only use the clipboard by using <ctrl>c twice before pasting, otherwise the clipboard does not get updated. From time to time, this leads to unwanted content to be pasted. I offer to test and collect any type of test data until this problem is finally solved. As there are not many updates in this bug, is there maybe a simpler workaround available? I wonder how all the other affected users work with this problem, or if the affected users all are using a special configuration.
Seems the bug is reported against mutter, but according to https://bugzilla.redhat.com/show_bug.cgi?id=1769236#c15 you're reproducing this in a KDE session, in which mutter plays no part. Maybe this should be moved to kwin? Does the clipboard issue always involve Firefox btw? The only clipboard issue I myself am experiencing (in F32 and F33) are related to Firefox, and hard to reproduce.
I just tested again. Currently, I am still observing the same symptoms as I described in https://bugzilla.redhat.com/show_bug.cgi?id=1769236#c15. Both problems are about copying text inside the Citrix session and pasting it to the Fedora 32 host system (= the session's primary selection: xsel -po, as well as the sessions's clipboard selection (middle mouse key): xsel -bo). The other way around (=from the host system to the ICA session) is currently working. Also copy and paste just in the host system's KDE session is working using the primary and clipboard selection. After some time of working with the ICA sessions, the following happens: When pressing <ctrl>c or <shift><ctrl>c with the expectation that this text will be transferred to the host system's primary or clipboard selection, this text will not be available in the host system's primary selection (I have to check if it appears in the clipboard selection, but I don't expect it). I so far have not found anything which triggers this behavior. The workaround I am using in this case is to transfer text via a Google document. Copying and pasting inside the Citrix VDI session is working, with the exception that the selected text will only be transferred to the session's primary selection every second time. Is there any additional data which I could collect to assist with the analysis? Last time I tested, I could reproduce the problem with other host system desktop environments as well. Please let me know which desktop environment you want me to test: cinnamon, enlightenment, gnome-classic, gnome, openbox, twm, or WindowMaker
This problem is also happening in Fedora 33. Please change the version.
On Fedora 33, I removed the clipit RPM, logged out, then back in. Problem seems to be fixed.
I've noticed that simply highlighting and middle-clicking has been broken for quite a while. I've been able to work around that by pressing Ctrl+C in most cases, but today the problem seems to have become much much worse. Now I cannot even highlight a block of text with the mouse. It seems like something is clearing/resetting the highlight as I move the mouse. I'm now down to using Shift+End or Shift+Home to highlight lines and then pressing Ctrl+C to get them into a clipboard. I don't have clipit installed. I'm running Fedora 33.
Created attachment 1769360 [details] video recording demonstrating problem In the attached video, I am holding the left mouse button down continuously as I try to highlight the lines of text.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Can anyone confirm if these issues have been fixed in F34?
I am seeing what look to be the same problems in F34. The first few weeks I did not have the issue, then it showed up last week. It is unclear what caused the break. I don't have clipit installed.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
How can I trace how (text only) data gets transferred to and from, and handled within, the X selection (=clipboard and primary selection) buffers? I ran some tests in the following environment: 5.12.11-300.fc34.x86_64 plasma-desktop.x86_64 5.22.2.1-1.fc34 ICAClient.x86_64 21.4.0.11-0 # env | grep -i sess DESKTOP_SESSION=plasmax11 XDG_SESSION_DESKTOP=plasmax11 XDG_SESSION_TYPE=x11 KDE_SESSION_VERSION=5 XDG_SESSION_ID=2 KDE_FULL_SESSION=true GDMSESSION=plasmax11 ... # echo $XDG_SESSION_TYPE x11 The Citrix ICA client session is a VDI system running RHEL 7.9, and I am trying to copy text only data between the host session and the VDI system and vice versa. I wrote a little script, show-clipboards.sh, to monitor the contents of the X selection buffers. I run it with watch -n 0.5 in a terminal window in the host session and also in the Citrix ICA client session: ---> #!/bin/bash # show-clipboards.sh: show the contents of all clipboards printf "Primary : " xsel -po | awk '{printf (">%s<\n", $0)}' printf "\nSecondary : " xsel -so | awk '{printf (">%s<\n", $0)}' printf "\nClipboard : " xsel -bo | awk '{printf (">%s<\n", $0)}' <--- In the below test results, "OK" means that a text is contained in the respective buffer. "no change" means that the respective buffer did not get updated. test 1: on the host OS, double click on a word in Chrome host primary: OK host clipboard: no change Citrix client primary: OK Citrix client clipboard: OK test 2: continue test 1 and press <shift><ctrl>c host primary: OK host clipboard: OK Citrix client primary: OK Citrix client clipboard: OK test 3: inside the Citrix UNIX client, double click on a word in a terminal window. host primary: no change host clipboard: no change Citrix client primary: OK Citrix client clipboard: no change test 4: continue test 3: Move the cursor outside the Citrix window. host primary: OK host clipboard: OK Citrix client primary: OK Citrix client clipboard: no change Up to this point, the data transfer between the clipboards works as expected. But after some minutes, or after certain copy/paste or other actions I am not aware of, the connection between the host and the Citrix session clipboards is broken: test 5: Repeat test 4 host primary: no change host clipboard: no change Citrix client primary: OK Citrix client clipboard: no change test 6: Repeat test 3 and press <shift><ctrl>c host primary: no change host clipboard: no change Citrix client primary: OK Citrix client clipboard: OK test 7: continue test 6: Move the cursor outside the Citrix window. host primary: no change host clipboard: no change Citrix client primary: OK Citrix client clipboard: no change test 8: Repeat test 1. host primary: OK host clipboard: no change Citrix client primary: no change Citrix client clipboard: no change test 9: Repeat test 2. host primary: OK host clipboard: OK Citrix client primary: no change Citrix client clipboard: no change
happens on a fresh up-to-date install of Fedora 35 using KDE plasma. 80% of the time copy works, 20% it doesn't.
is it worth bumping up the version to 35? anyone got a test I can run that can provide the needed info?
(In reply to Rory Renton from comment #30) > happens on a fresh up-to-date install of Fedora 35 using KDE plasma. > > 80% of the time copy works, 20% it doesn't. This bug is about copy paste in the default Workstation session (GNOME). For KDE plasma, another bug should be created, probably against 'kwin'.
if the bug is in 2 things, shouldn't it be dealt with and reported upstream? where would you suggest?
This is purely anecdotal, but I just uninstalled jitterentropy-3.3.1-1.fc34.x86_64 and its two dependencies (rng-tools-6.14-2.git.b2b7934e.fc34.x86_64 and rtl-sdr-0.6.0-9.fc34.x86_64) and the problem "seems" a lot less severe (still not perfect though). Maybe it is something others can experiment with to see if it makes any measurable difference on their systems.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.