*** Bug 424731 has been marked as a duplicate of this bug. ***

Is this fixed with p-w as of today? It should be

No not fixed yet. I still have empty entries in klipper and still stuff not copied on Ctrl+C in XWayland apps.

(In reply to Leszek Lesner from comment #3)
> No not fixed yet. I still have empty entries in klipper and still stuff not
> copied on Ctrl+C in XWayland apps.

Figured out if you disable "Prevent empty keyboard" it seems to work!? Ctrl+C works directly in XWayland apps like Chromium/Firefox and co

it's still reproducible.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2

(In reply to Leszek Lesner from comment #4)
> (In reply to Leszek Lesner from comment #3)
> > No not fixed yet. I still have empty entries in klipper and still stuff not
> > copied on Ctrl+C in XWayland apps.
> 
> Figured out if you disable "Prevent empty keyboard" it seems to work!?
> Ctrl+C works directly in XWayland apps like Chromium/Firefox and co

yes, I can't reproduce if "Prevent empty clipboard" is uncheched in clipboard applet settings.

Turns out I hadn't merged my workarounds...so potentially my fix is still fine.

Also upstream protocols approved my idea for a proper fix so I'll work on that soon.

(In reply to David Edmundson from comment #7)
> Also upstream protocols approved my idea for a proper fix so I'll work on
> that soon.

Was it public discussion? I would love to follow.

https://github.com/swaywm/wlr-protocols/issues/92

*** Bug 426713 has been marked as a duplicate of this bug. ***

*** Bug 427832 has been marked as a duplicate of this bug. ***

I experience this since the update to Plasma 5.20. The behavior is rather frustrating and might lead to data loss if you think you have copied (or cut out) something, close it and then when trying to paste it nothing is pasted.

Also at least from a user perspective it appears as a regression (although technically it might not be true).

Added the regression keyword and moved importance to HI and major due to the possibility of data loss and the user frustration to be expected.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/365

*** Bug 428075 has been marked as a duplicate of this bug. ***

Git commit d335070b80c2f3bc5674355e3edba61bc010bc36 by Aleix Pol.
Committed on 29/10/2020 at 14:56.
Pushed by apol into branch 'master'.

xwl: Do not refresh the x11 Clipboard while fetching

At the moment there was a race condition when putting something into the
keyboard from XWayland apps. The clipboard manager would announce a new
thing before we'd submitted it all resulting in a broken state.

This change detects when it's fetching and will only refresh the source
after everything has been sent.
Related: bug 412350

M  +10   -0    xwl/clipboard.cpp
M  +1    -0    xwl/clipboard.h

https://invent.kde.org/plasma/kwin/commit/d335070b80c2f3bc5674355e3edba61bc010bc36

Won't this get backported to 5.20? I personally consider the experience rather frustrating and would be pretty disappointed if I had to wait about three months in this state until it is fixed.

Ignore that, it seems to be planned to backport this, probably just have to wait a short time.

*** Bug 428521 has been marked as a duplicate of this bug. ***

Built from git master, i am still encountering this issue, and infact i think it's worse than before. I am completely unable to copy or paste between a Wayland and XWayland application now. Before this i used to be able to paste sometimes by using the middle mouse button, but even that doesn't work at all now.

Git commit 99b29195b45ecc0de97761f13e7df81dd92b53e7 by Nate Graham, on behalf of Aleix Pol.
Committed on 28/11/2020 at 22:33.
Pushed by ngraham into branch 'Plasma/5.20'.

xwl: Do not refresh the x11 Clipboard while fetching

At the moment there was a race condition when putting something into the
keyboard from XWayland apps. The clipboard manager would announce a new
thing before we'd submitted it all resulting in a broken state.

This change detects when it's fetching and will only refresh the source
after everything has been sent.
Related: bug 412350
(cherry picked from commit d335070b80c2f3bc5674355e3edba61bc010bc36)

M  +10   -0    xwl/clipboard.cpp
M  +1    -0    xwl/clipboard.h

https://invent.kde.org/plasma/kwin/commit/99b29195b45ecc0de97761f13e7df81dd92b53e7

I think there's more to this bug than just the race condition, especially since i still encounter this. I think a partial cause is that window focus issues make it so that the clipboard cannot be accessed.

At line 141 in https://invent.kde.org/plasma/kwin/-/blob/0549c14588e0ccdbd4d78bb710e1c7569b409247/xwl/clipboard.cpp it seems it's checking for XWayland application focus before allowing the use of the clipboard. However, if the window focus is broken, then this would not work obviously, hence why it is still breaking despite this patch?

Would you be interested in hacking on it a bit and submitting a merge request?

(In reply to Nate Graham from comment #22)
> Would you be interested in hacking on it a bit and submitting a merge
> request?

I wish i could, but i have no idea how Kwin works, and it isn't an issue with the clipboard code i shared but rather window handling.

Since you seem to be familiar with compiling with kdesrc-build, what you could try to do is to modify the code at the line you found to be possibly suspicious and add debug output to see how the code behaves for you. That could at least confirm your theory that this has something to do with window focus and https://bugs.kde.org/show_bug.cgi?id=400987.

However that might take time while not delivering helpful information. But it would be something you probably can do.

Further information on how to get console output for example can be found here: https://www.proli.net/2020/04/03/developing-kwin-wayland/.

I can reproduce this problem with the steps already provided using Firefox
or Opera browsers.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.20.80
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

I can reproduce this problem with the steps already provided using Firefox flatpak version.


Operating System: KDE neon 20.04 Testing Edition
KDE Plasma Version: 5.20.90
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2

https://bugzilla.mozilla.org/show_bug.cgi?id=1631061

Seems to have been fixed now?

No. Firefox is not the only affected app.

Patrick, is this still reproducible for you with current Neon unstable?

Currently this bug is harder to reproduce, but it persists.
Sometimes Clipboard applet shows an empty entry after copying a word,
then pasting fails.

Firefox 86.0.1
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.21.80
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Graphics Platform: Wayland

Perhaps related to this bug: https://bugs.kde.org/show_bug.cgi?id=422426#c14

I can reproduce this in Chrome as well, on Fedora 34 beta.

This early return looks horribly wrong.

```
void Clipboard::wlSelectionChanged(KWaylandServer::AbstractDataSource *dsi)
{
    if (m_waitingForTargets) {
        return;
    }
```

It needs to discard the old async operation, not discard the new one.

gtk 3.24.29 was released today and is already packaged in Arch Linux, so I tested there.

Primary selection now works fine between a Qt app (konsole) and most GTK3 apps (gnome-disks, seahorse, tilix).

However, it still fails between Qt apps and GTK3 apps which are still using X11 (Chrome, Firefox, Thunderbird, Signal Desktop).

I checked, and these binaries are using the new libgtk-3.so:

  % cat /proc/$(pidof -s chrome)/maps | grep -m1 gtk 
  7fab70d09000-7fab70d8c000 r--p 00000000 103:03 17587682                  /usr/lib/libgtk-3.so.0.2404.25
  % cat /proc/$(pidof -s thunderbird-bin)/maps | grep -m1 gtk 
  7f87486d7000-7f874875a000 r--p 00000000 103:03 17587682                  /usr/lib/libgtk-3.so.0.2404.25

Not sure if this is a kwin bug, or the gtk bug is not fully fixed yet.

Ah, this is a known issue:
https://bugs.kde.org/show_bug.cgi?id=422426#c24

"Primary selection will still not work between QT-Wayland and e.g. Chromium or Pidgin. In order to fix that kwin will need to translate between primary selection of Wayland and X11 - that's not yet done, so the bug should get reopened."

Looks like we could close one of these bugs as duplicate of the other.

And this, imho, should be a Wayland showstopper because it breaks all a very basic workflow (copying text between KDE apps and browsers plus all electron UI apps).

I can still reproduce this bug on my Fedora 34 (KDE spin) system.

SOFTWARE/OS VERSIONS
OS: Fedora 
Kernel: x86_64 Linux 5.11.15-300.fc34.x86_64
DE: KDE 5.80.0 / Plasma 5.21.4

(In reply to Armin from comment #36)
> I can still reproduce this bug on my Fedora 34 (KDE spin) system.
> 
> SOFTWARE/OS VERSIONS
> OS: Fedora 
> Kernel: x86_64 Linux 5.11.15-300.fc34.x86_64
> DE: KDE 5.80.0 / Plasma 5.21.4

This is already being tracked in the RH bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1954147

I have another use case that doesn't involve GTK or XWayland.

1. Open Kate, open Konsole.
2. Copy test from Kate, paste in Konsole - works.
3. Copy another text from Kate and paste in console - nothing is getting pasted. Klipper shows empty text for the current buffer.

Both Konsole and Kate are Wayland windows, no XWayland windows are active during this test.

Plasma: 5.22.3.

Should I open another bug about it or it falls into the same one?

If XWayland is not involved, that sounds like a different bug. :)

(In reply to Nate Graham from comment #39)
> If XWayland is not involved, that sounds like a different bug. :)

OK, I'll open another one. But the symptom looks very similar.

Opened bug 439765.

Actually I think you're right; they are the same after all. Sorry for sending you on a wild goose chase.

*** Bug 439765 has been marked as a duplicate of this bug. ***

*** Bug 439513 has been marked as a duplicate of this bug. ***

*** Bug 441783 has been marked as a duplicate of this bug. ***

This has been cleaned up for 5.23. Please create a new bug if there are still issues, with some newer logs.