Subject: Re: [X2Go-Dev] Bug#1633: New clipboard issue in Libreoffice with X2Go

From: Jens Reyer <[email-masked]>
Date: Tue, 25 Mar 2025 11:59:33 +0100 (CET)

Hi

sorry for the late reply. I made my answers inline:

> 
>     Ulrich Sibiller <[email-masked]> hat am 17. März 2025 um 21:35 geschrieben:
> 
>     Hello again,
> 
>     I had a look at the logfile. It's been a while since I worked on the
>     clipboard code. But I _think_ there are a few things you should test:
> 
>         * restrict clipboard to text only: add X2GO_NXAGENT_DEFAULT_OPTIONS+="
>           -textclipboard" to /etc/x2go/x2goagent.options on the server side and
>           start a NEW session (no reconnect). Does that help?
> 

No, same behavior.

But I kept this setting for all further tests.

>         * not sure what exactly you have been doing while creating the sessionlog. But I can seen "caja" on the server side requesting clipboard.
>           Please try to run a session without caja (which is a file manager,
>           unclear what it does with selections).
> 

See new session.log without any caja mention, from a client with twm/xterm to a session with twm on the server. There I started xterm, then did a "libreoffice --calc /home/localadmin/test.ods" and did several ctrl+c ctrl+v in that calc document.

>         * it _looks_ like something on the client side is requesting theclipboard when you are doing your tests. The question is what program
>           is doing that. If possible run a few programs on the client side,
>           preferably only a very simple session (fvwm twm or so) and an xterm.
>           Run x2goclient from there.
>           To find out what program on the client side is requesting the
>           clipboard you can check the server log file for lines like this:
>           nxagentHandleSelectionRequestFromXServer: Received
>           SelectionRequestEvent from real server: selection [529][CLIPBOARD]
>           target [469][TARGETS] requestor
>           [display[nx,options=/tmp/.x2go-localadmin/C-localadmin-50-1742211621_stDMATE_dp24/options:50.0]/0xe09e31]
>           destination [386][GDK_SELECTION] time [13640727]. The bold number is
>           the requestor. You can check that with xwininfo -id <number> on the
>           client.
> 

The bold marking went missing, so I just  tested all ids.

>From client mate to server twm I always get "No such window ...", e.g.

me@client:~$ xwininfo -id 531
X Error: 9: Bad Drawable
Request Major code: 14
ResourceID in failed request: 0x213
Serial number of failed request: 3
xwininfo: error: No such window with id 0x213.

Then I tested from the twm/xterm client to a twm/xterm session on the server, see the attached Bug1633_nxagentHandleSelectionRequestFromXServer.log

>         * there's an option to include the clipboard content (or rather thedata being transferred) in the session log in DEBUG mode. This helps
>           in identifying what stage we are in. Change #undef
>           PRINT_CLIPBOARD_CONTENT_ON_DEBUG to #define and recompile
> 

Done, see new session.log.

>         * while at it you could also try to change the timeout for theclipboard transfer. I hardcoded 5s when I wrote all this and it was ok
>           for me ever since. But YMMV. #define CONVERSION_TIMEOUT 5000. In your
>           log I see errors like this "nxagentConvertSelection: got new request
>           before timeout expired on previous request, notifying failure to
>           client [20] (addr [0x557c39ea2f40] PID [18630] Cmd
>           [/usr/lib/libreoffice/program/soffice.bin])". This means that the
>           previous clipboard-related communication has not finished when soffice
>           starts another request which then is denied. So this indicates that
>           some answer from the client side is still due. I suspect that this
>           answer is never sent so your diagnosis that every second paste is
>           working might in fact resemble a 5s pattern. Meaning: you can only
>           successfully paste every 5s, but not quicker. So I suggest to decrease
>           the timeout to 2s or so and see if that makes a difference for you.
>           One thing here is strange here, though: Doing a copy in soffice on the
>           server side makes soffice the clipboard owner. So while you are
>           working inside soffice there should be no communication to the client
>           that awaits any answer. Which again leads me to the suspicion that
>           there's some clipboard manager involved.
> 

First I tried waiting for 15 seconds after copying: this does NOT help.

Then I recompiled with #define CONVERSION_TIMEOUT 2000, same behavior, see new session.log

>         * x11 clipboard transfers are size restricted. That means that biggerselections are to be transferred to the requestor in multiple packets.
>           nx does not support this currently, so you are restricted to 256kB. Is
>           it possible that your selection is bigger than that?
> 

No, its always just a few characters.

>         * I also see SelectionClear requests from the client side. Which alsoindicates there's something dealing with clipboard on the client side.
> 

I still see SelectionClear in the new twm/xterm to twm/xterm session.log, but I'm not sure which side they are from.

>         * I played around with these tools:https://github.com/phillbush/xcliputils Using xclipowner -w you can
>           watch if the clipboard owner changes. Run that on the client and then
>           do clipboard stuff in libreoffice on the server. The owner as printed
>           by xclipowner should never change except for the first time. If it
>           does we have another indication of a clipboard-manager-in-the-middle
>           attack ;-)
> 

>From client Mate to server twm a successful ctrl+c results in

0x03C0016A

and a failed ctrl+c results in a

0x00000000
0x03C0016A

>From twm/xterm client to a twm/xterm session on the server both failed and successful ctrl+c results in

0x00E0016A

Thanks and greets