STEPS TO REPRODUCE 1. Open an XWayland application. 2. Copy some text from it. 3. Paste it in kate. 4. Close the XWayland application from which you copied the text at step (1). 5. Try to paste it in kate, again. OBSERVED RESULT At step (3) the copied text is pasted, as expected. At step (5) nothing is pasted. EXPECTED RESULT Both steps (3) and (5) should have pasted the same text copied at step (1). SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 + KDE patches ADDITIONAL INFORMATION This is definitely not a regression.
Can you provide an example of an XWayland app where this happens? I cannot reproduce the issue with Discord or Element.
You can reproduce it using Firefox. Make sure that it is indeed using XWayland by checking the "Window Protocol" field in "about:support".
Can you confirm what klipper shows?
Klipper keeps the copied text after exiting the XWayland application. If you click on its entry in klipper, you can indeed paste the text again.
Alternate formulation of this bug: If an XWayland application is closed instead of just losing focus, its clipboard contents are lost and not synced to Klipper.
Can reproduce with Firefox on Wayland session of Gnome too. https://gitlab.gnome.org/GNOME/mutter/-/issues/1532 Recent comments say it's a Firefox issue.
Can anyone find or file a bug report for Firefox? And tell them GNOME people too.
This affects other applications as well.
Which ones?
All of them. Every application that isn't Wayland-native.
I can't reproduce that.
Perhaps klipper's settings are important? I don't have enabled the "Keep the selection and clipboard the same" and "Save history across desktop sessions", and both "Text selection" and "Non-text selection " are set to "Only when explicitly copied". 20 Entries and no actions.
Hmm, now I can reproduce this issue 100% with Discord, no matter what Klipper settings I use.
This is 100% repeatable for me with and copying from any XWayland application and trying to paste after closing it. I haven't changed any clipboard settings on the system. And what's worse, is that there's a bug in `wl-clipboard` that causes `wl-paste` to hang when this happens https://github.com/bugaevc/wl-clipboard/issues/185, which in turn causes Neovim to hang, since it uses `wl-paste` under the hood. I'm using: KDE Plasma 5.27.6 on Arch Linux
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4326
Git commit f7fb9476b37b648298e6d329ff0aad4f5ca550c1 by Vlad Zahorodnii, on behalf of David Edmundson. Committed on 21/08/2023 at 09:58. Pushed by vladz into branch 'master'. xwl: Handle X11 clipboard owners closing more thoroughly Selection acts as an abstraction around multiple X11Sources, when we get a new source we asyncronously emit that x11OffersChanged when it completes. If the selection is lost, we were just deleting the source, without notifying other parts. XwlDataSource is the datasource that SeatInterface knows about. We need to delete this when the X11 connection is no longer valid. SeatInterface will update the selection when the XwmlDataSource is deleted if it's the active selection. The hook is introduced as updating the selection in Clipboard will cause Selection to delete m_xSource which gets messy. M +5 -0 src/xwayland/clipboard.cpp M +1 -0 src/xwayland/clipboard.h M +4 -0 src/xwayland/dnd.cpp M +1 -0 src/xwayland/dnd.h M +5 -0 src/xwayland/primary.cpp M +1 -0 src/xwayland/primary.h M +4 -2 src/xwayland/selection.cpp M +1 -0 src/xwayland/selection.h https://invent.kde.org/plasma/kwin/-/commit/f7fb9476b37b648298e6d329ff0aad4f5ca550c1