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.