https://bugs.kde.org/show_bug.cgi?id=512183
synopses616 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |t --- Comment #6 from synopses616 <[email protected]> --- Reproducible 100% of the time here on Plasma 6.6.5 / Frameworks 6.26.0 / Qt 6.11.1 (CachyOS, 5120x2160 display). I think I found the cause. It's not 4K-specific and not the portal: it still happens with xdg-desktop-portal-kde stopped. Klipper loses a race against the source app exiting. I watched the seat selection with a small ext-data-control client. Spectacle's own offer is fine, reading image/png from it returns the full ~2MB PNG while spectacle is still running. When spectacle exits ~300ms later (the auto-copy path quits immediately), klipper takes over the selection, but reading image/png from klipper's offer returns 0 bytes; nothing ever opens the write end of the pipe. The result is also visible on disk: in ~/.local/share/klipper/data/ every image entry is a 0-byte file named da39a3ee5e6b4b0d3255bfef95601890afd80709, which is sha1(""). Text entries are stored fine. I think this explains the earlier observations too. The "Unsaved Screenshot" window workflow (comment 2) works because spectacle stays running and serves the clipboard itself. Larger screenshots fail more often simply because the transfer takes longer relative to how quickly spectacle exits, which would be why comment 4 couldn't reproduce on 3840x1080: a smaller PNG usually wins the race. A test clipboard owner that I keep running serves images indefinitely, including to XWayland clients, so everything downstream of klipper is healthy. Workaround: running wl-clip-persist (--clipboard regular) fixes screenshot pasting completely, since it reads the data eagerly and re-owns the selection when the source dies. Klipper's history stays broken though, the stored blobs are empty, so pasting an older image entry from the popup still yields nothing. Can share the monitor source and full traces if useful. -- You are receiving this mail because: You are watching all bug changes.
