wl-copy does not copy files under kwin

[MrDrMcCoy]

When I run wl-copy -pt image/gif < bueller.gif, it exits immediately, but does not copy anything into the clipboard. When I run wl-copy -fpt image/gif < bueller.gif, it hangs, and does not copy anything into the clipboard.

This is with version 2.2.1-1 (from Debian Trixie) under KDE 6.0.5.

Here are the outputs of WAYLAND_DEBUG=1 strace -vkinyyYo strace-wl-copy.txt wl-copy -fpt image/gif < bueller.gif: strace-wl-copy.txt WAYLAND_DEBUG.txt

[bugaevc]

Hi, thanks for the clear report! So from the logs you posted it looks like it does successfully copy your GIF into the clipboard. So how do you know that it "does not copy anything into the clipboard", what are the symptoms? Are you trying to paste it somewhere (where?) and it fails to paste? (If so, it's likely that the other app/client just doesn't support pasting image/gif.) Are you able to paste using wl-paste?

[MrDrMcCoy]

Symptoms are that after copying the file with wl-copy, Klipper does not show any new clipboard entries, and pasting gives me what was in there before. Doesn't matter where I paste. I've also tried with jpeg and png files, but get the same behavior.

I tried a new test just now: copying a plain text file. That successfully populates Klipper with a new entry and pasting works as expected. Seems this has something to do with binary data somehow.

[MrDrMcCoy]

I was mistaken. Copying an image from another app that I can paste from never makes an entry in Klipper, and wl-copy appears to fill the clipboard with nothing, so pasting does not give me what was in there last, it's just nothing.

The example apps I tried to paste into are Slack and Discord, which definitely accept clipboard image data when copied from other apps.

[bugaevc]

Could you try wl-paste --list-types, wl-paste > /tmp/pasted.gif?

[MrDrMcCoy]

The plot thickens.

3.2ms 11:11am 06/07 $ wl-copy < Nextcloud/reactions/and\ yet.jpeg
19.7ms 11:11am 06/07 $ wl-paste --list-types; wl-paste > /tmp/pasted.jpeg
image/jpeg
17.5ms 11:11am 06/07 $ kioclient exec /tmp/pasted.jpeg

This opens a valid jpeg image in Gwenview. Pasting that immediately into Discord/Slack does nothing. Re-copying the pasted image into Slack from Gwenview gives an "unsupported file type" message, while Discord populates an empty image. Pasting into LibreOffice Draw actually gives me the image, and re-copying it again from LibreOffice allows pasting into Slack/Discord successfully.

Maybe a few bytes of metadata are getting lost and reconstructed in this process somehow?

[luluco250]

I think I'm also hitting this issue, it almost seems to depend on the "complexity" of the text file...?

For example, echo foo > foo; wl-copy < foo, Klipper (KDE's clipboard manager) shows foo was copied properly and I can paste it. echo foo | wl-copy and cat foo | wl-copy also work.

However, when I try to copy the following text from a file, it doesn't copy:

Sample text file

#!/bin/bash

set -euo pipefail
IFS=$'\n\t'

domain=foo.bar.com
user=me
ip=192.168.1.69
secret_attribute=rdp-password
secret_value=foo

main() {
    args=(
        /d:"$domain"
        /u:"$user"
        /from-stdin
        /v:"$ip"
        /dynamic-resolution
        -grab-keyboard
        -grab-mouse
        -encryption
        -toggle-fullscreen
        +clipboard
        -themes
        -wallpaper
        /gfx:AVC444
        /audio-mode:2 # Disable audio
        # -compression
    )
    pass=$(secret-tool lookup "$secret_attribute" "$secret_value")
    pass_status=$?
    
    if [ "$pass_status" -ne 0 ]; then
        msg_error 'Failed to obtain password'
        exit 1
    fi
    
    exec xfreerdp "${args[@]}" <<< "$pass"
}

# Shell level is 1 when launched from a desktop file,
# so we'll use GUI for messages.
if (( SHLVL == 1 )); then
    msg_info() {
        kdialog --msgbox "${@}"
    }

    msg_error() {
        kdialog --error "${@}"
    }
else
    msg_info() {
        echo "${@}"
    }

    msg_error() {
        2>&1 echo "${@}"
    }
fi

main "${@}"

I have tested seq 1000 | wl-copy and seq 1000 > foo; wl-copy < foo and both copy/paste properly, so I'm not sure exactly what causes certain text files to fail to copy.

I should note that if I open the text file in a GUI application like KWrite, Codium, LibreWolf etc, it copies properly.

Interestingly the micro text editor, which uses wl-clipboard under Wayland, seems to be completely broken for me and won't copy even simple lines.

I'm using the Fish shell in case that matters.

[bugaevc]

However, when I try to copy the following text from a file, it doesn't copy

Quite likely it does get copied, but not as a type you expect. What does wl-paste --list-types say?

In my system here, a shell script gets detected as application/x-shellscript, which wl-copy correctly recognizes as a text file. But if not, you might have to use --type text/plain explicitly.

[luluco250]

The --type text/plain flag did the trick, wow.

I should've phrased it properly, it did paste successfully with wl-paste and wl-paste --list-types also listed it as application/x-shellscript, but any GUI clipboard interactions under KWin with that mimetype don't seem to work, such as Ctrl+V or Ctrl+Shift+V within the same terminal or any other GUI application.

Maybe KDE tries to filter shellscripts or it doesn't handle them in their clipboard system?

That leaves only the mystery of why micro isn't working for me (or rather, it only works inside itself, but won't paste outside), dunno if it might be related to the same issue.

Out of curiosity, is there a good reason to set a mime type for non-binary text files?

Update, this seems to be exactly what's affecting micro for me. If I copy, from the same open text file/buffer, for example:

domain=foo.bar.com
user=me
ip=192.168.1.69
secret_attribute=rdp-password
secret_value=foo

I get:

$ wl-paste --list-types
STRING
text/plain;charset=utf-8
text/plain
TEXT
UTF8_STRING

And pasting on GUI apps works fine.

If I copy:

#!/bin/bash

set -euo pipefail
IFS=$'\n\t'

I get:

$ wl-paste --list-types
application/x-shellscript

And GUI pasting is broken, i.e. I cannot paste from micro somewhere else.

[bugaevc]

But this logic here should already handle application/x-shellscript...

https://github.com/bugaevc/wl-clipboard/blob/091d6028b5c9db75ad36f9fceb0db3ee718045fa/src/util/string.c#L37

[luluco250]

I figured it out, turns out I had wl-clipboard-rs installed instead of wl-clipboard. I guess it's a bug on their end.

Seems to be working with the original wl-clipboard.

Apologies for the confusion!