Bug 462979

Caused by https://invent.kde.org/frameworks/kguiaddons/-/commit/3984732e007e71632a525d89227fdfe94fa037ad

I will take a look

Works for me.

Can you check in the KWin debug console (it's the rightmost tab) if plasma gains the clipboard once you click on an item  ? Should say wl_data_source@X of plasmashell.

A Wayland log could also be helpful.

The clipboard content in the debug console is not changed when selecting an item in Klipper

> A Wayland log could also be helpful.

You mean WAYLAND_DEBUG=1 plasmashell?

> You mean WAYLAND_DEBUG=1 plasmashell?
Yeah

Created attachment 154572 [details]
plasmashell while changing clipboard item

I can reproduce it as well. The moment I choose a clipboard item from the history, I can no longer paste anything until I copy something again - except in plasmashell where it works as expected (eg. in a sticky note)

Calling setClipboardContents from dbus changes the clipboard correctly. getClipboardContents returns the current clipboard item in klipper but it's not necessarily the same as in KWin debug console

I attached output of "journalctl -f -o cat _COMM=plasmashell" in which I change a clipboard item via super+v shortcut, and wait a bit for the log to be populated

Created attachment 154574 [details]
plasmashell while using setClipboardContents

Ah I think I see what happens, 

[1053774.850] wl_keyboard@3.key(4212, 1455065, 96, 1)
[1053774.988]  -> xdg_toplevel@70.destroy()
[1053775.005]  -> xdg_surface@232.destroy()
[1053775.030]  -> wl_display@1.sync(new id wl_callback@230)
[1053775.049]  -> wl_surface@222.destroy()
[1053775.077]  -> org_kde_kwin_shadow@76.destroy()
[1053775.170]  -> zwp_primary_selection_device_manager_v1@11.create_source(new id zwp_primary_selection_source_v1@85)
[1053775.187]  -> zwp_primary_selection_source_v1@85.offer("text/plain")
[1053775.198]  -> zwp_primary_selection_source_v1@85.offer("text/plain;charset=utf-8")
[1053775.213]  -> zwp_primary_selection_device_v1@12.set_selection(zwp_primary_selection_source_v1@85, 4212)
[1053775.226]  -> zwp_primary_selection_source_v1@233.destroy()
[1053775.247]  -> wl_data_device_manager@9.create_data_source(new id wl_data_source@187)
[1053775.262]  -> wl_data_source@187.offer("text/plain")
[1053775.272]  -> wl_data_source@187.offer("text/plain;charset=utf-8")
[1053775.286]  -> wl_data_device@10.set_selection(wl_data_source@187, 4212)
[1053775.298]  -> wl_data_source@228.destroy()
[1053788.959] discarded [zombie]@233.[event 1](0 fd, 8 byte)
[1053789.027] discarded [zombie]@228.[event 2](0 fd, 8 byte)
[1053789.095] wl_display@1.delete_id(70)
[1053789.109] wl_display@1.delete_id(232)
[1053789.119] wl_display@1.delete_id(230)
[1053789.130] wl_display@1.delete_id(222)
[1053789.140] wl_display@1.delete_id(76)
[1053789.150] wl_display@1.delete_id(233)
[1053789.159] wl_display@1.delete_id(228)
[1053790.209] wl_keyboard@93.leave(4213, nil)
[1053790.226] wl_keyboard@3.leave(4213, nil)

Klipper applet hides and then only afterwards sets the clipboard, but keyboard_leave is only sent afterwards so in KSystemClipboard we think we still have focus.

FWIW I tested with Klipper applet being pinned where this doesn't happen.

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

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/83

Git commit 0fbb0aa524adbd077b2ba7716218d4c6f042bed0 by David Edmundson, on behalf of David Redondo.
Committed on 04/01/2023 at 08:51.
Pushed by davidedmundson into branch 'master'.

waylandclipboard: Be a bit smarter about when to use the QGuiApplication::clipboard

The newly introduced keyboardFocusWatcher suffers from a similar problem on keyboard
leave as the one it fixed on keyboard enter.
When  Qt hides a window,  the focusWatcher and itself think that the
app has focus because keyboard_leave did not arrive yet but setting the
normal clipboard will still fail. This is an issue in klipper as it shows this
pattern of window hide and afterwards setting the clipboard.
To workaround this we can check if the focusWindow is visible even though
we still think we should have focus.
FIXED-IN:5.102

M  +3    -1    src/systemclipboard/waylandclipboard.cpp

https://invent.kde.org/frameworks/kguiaddons/commit/0fbb0aa524adbd077b2ba7716218d4c6f042bed0