wl-copy causes window to briefly appear

[eliasreid]

To reproduce I just need to run wl-copy <some-text> from the command line. The same issue happens through other applications as well, for example if copying to system clipboard from neovim. I don't see the issue when copying text on the terminal by selecting with mouse and using Ctrl+Shift+C shortcut (or context menu)

Screencast_20251105_233354.webm

My config file is just:

startup_apps:
  - command: konsole

Other system info in case relevant:

Operating System: Nobara Linux 42
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.2
Kernel Version: 6.17.5-200.nobara.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 3080
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C91
System Version: 2.0

I assume this is related to the first paragraph here: https://man.archlinux.org/man/wl-clipboard.1#BUGS

Unless the Wayland compositor implements the wlroots data-control protocol, wl-clipboard has to resort to using a hack to access the clipboard: it will briefly pop up a tiny transparent surface (window). On some desktop environments (in particular when using tiling window managers), this can cause visual issues such as brief flashing. In some cases the Wayland compositor doesn't give focus to the popup surface, which prevents wl-clipboard from accessing the clipboard and manifests as a hang.

[mattkae]

Interesting! I wonder if we can detect what "type" that surface is and refuse to show it... Otherwise, we should eventually support the new protocol (which I think is currently in progress upstream? at least ext data control is coming)