Bug 511989

To clarify: enable_clipboard is false but the clipboard does work, right?

Sorry, I forgot to add that clipboard does not work and calling for example Clipboard.SetSelection will result in an error:
> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Clipboard not enabled

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/472

I applied the patch in https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/472.

Now, enable_clipboard returns true as expected, and I don't get any AccessDenied errors when calling SetSelection. Thanks for the quick fix :)

I am now able to successfully read from the clipboard. 

Writing to the clipboard does not seem to work, not sure if it might be something incorrect with my implementation. After calling SetSelection, I never get the SelectionTransfer signal. Will have to do some further digging here.

Git commit 48ee6022aa4f34c88ad940d95235b679f355a921 by Harald Sitter.
Committed on 13/11/2025 at 08:18.
Pushed by sitter into branch 'master'.

remotedesktop: correctly set clipboard_enabled

unclear if this will fix the bug but it definitely isn't correct to just
always return false

M  +1    -1    src/remotedesktop.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/48ee6022aa4f34c88ad940d95235b679f355a921

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/473

Git commit b7f2107d0eb35d2b4cfccf9ffaa91437b88eff0a by Harald Sitter.
Committed on 13/11/2025 at 10:33.
Pushed by sitter into branch 'Plasma/6.5'.

remotedesktop: correctly set clipboard_enabled

unclear if this will fix the bug but it definitely isn't correct to just
always return false


(cherry picked from commit 48ee6022aa4f34c88ad940d95235b679f355a921)

Co-authored-by: Harald Sitter <sitter@kde.org>

M  +1    -1    src/remotedesktop.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/b7f2107d0eb35d2b4cfccf9ffaa91437b88eff0a

Ok so I've noticed two things after further digging:

1. Whenever I set mime_types in SetSelection, I will only ever get requests for "text/plain" in SelectionTransfer. This limits writing to the clipboard to only ASCII characters. Reading from the clipboard on the other hand seems to work as expected, I have no issues reading utf-8 strings with "text/plain;charset=utf-8".

2. In my SelectionWrite reponse-handler, whatever I am writing into the FD will get repeated (seemingly arbitrarily) many times. I thought this might have something to do with missing a null-terminator, but including one does not really fix the issue.

So for example, here is some sample code of trying to write "ab" to the clipboard:
> int written;
> int remaining;
> const char* data;
> 
> char s[] = { 97, 98, '\0' };
> remaining = 3;
> data = s;
> 
> while (remaining > 0) {
>   written = write(fd, data, remaining);
> 
>   if (written < 0) {
>     vlog.error("Error writing to fd: %s", strerror(errno));
>     selectionWriteDone(serial, false);
>     g_object_unref(fdList);
>     close(fd);
>     return;
>   }
> 
>   remaining -= written;
>   data += written;
> }
> 
> if (close(fd) != 0) {
>   vlog.error("Failed to close fd: %s", strerror(errno));
>   selectionWriteDone(serial, false);
> } else {
>   selectionWriteDone(serial, true);
> }
If I include the null-terminator (remaining = 3) and try to paste into Konsole, I get a Confirm Paste warning with between ~3k and 100k characters of repeated "ab", and a warning about pasting hidden control characters U+0000. Pasting with the null character will simply paste "ab" to the terminal.

If I don't include the null-terminator (remaining = 2), I still get the Confirm Paste warning with ~3-100k characters.

Note that the number of characters printed (~3-100k) will differ between each paste, and not between every time I write to the clipboard.

Maybe this bug should be closed, and a new one opened for this issue? Or would you prefer to keep it here?

> Maybe this bug should be closed, and a new one opened for this issue? Or
> would you prefer to keep it here?

I've created two new bugs: bug 512075, bug 512076.