X2Go Bug report logs - #1633
New clipboard issue in Libreoffice with X2Go

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#1633: New clipboard issue in Libreoffice with X2Go
Reply-To: Jens Reyer <jens.reyer@leberrohstoffe.com>, 1633@bugs.x2go.org
Resent-From: Jens Reyer <jens.reyer@leberrohstoffe.com>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Mon, 07 Apr 2025 11:55:01 +0000
Resent-Message-ID: <handler.1633.B1633.17440266862532475@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 1633
X-X2Go-PR-Package: x2goserver
X-X2Go-PR-Keywords: 
References: <CANVnVYLkcoG0nfM1j5kRJ2yYxX2TTiBcc3k6QuqYPLG7Q6FW5w@mail.gmail.com> <810710459.135614.1741783851926@195.98.208.36> <CANVnVYL+si4Dn5OypG3iBYgwD-uf-n=mgLmWbFj6eoTv47S0aA@mail.gmail.com> <CANVnVYJX1DNocs6252Vin_G-_W8+h4amJ2wFgmu0AV6A=BqVhA@mail.gmail.com> <1728065184.137568.1741862572763@195.98.208.36> <1081187274.137588.1741862691938@195.98.208.36> <CANVnVY+DBpxq8E8KrAdP75+YEsKGM-Eup9dADxyCnntwjz8uLw@mail.gmail.com> <1748520028.138240.1741874623478@195.98.208.36> <CANVnVYLD5DjxtGQpb=S_0_95eMW2=Up0z1napK6CqTBuNTTa6A@mail.gmail.com> <192506419.142362.1742212383293@195.98.208.36> <CANVnVYK=JUV9-xmZPdOcme0SEFqk+jsxLEL7WJyYJQ2Eg3qk=Q@mail.gmail.com> <999247165.134927.1741773596827@195.98.208.36> <CANVnVYLAGWS4Kc5xpv-dAGhrbUuQXU5Fs258oHP6Fxewvas3XQ@mail.gmail.com> <240682715.155126.1742900373833@195.98.208.36> <CANVnVYLWvKWX0Dg+P=sr1Khv3G7ZxFfaUEts_KRfdMnXaVOoTw@mail.gmail.com> <CANVnVYK4U9eqw59E7aYiLA-58D_aXNTJ1Fh961-OP5Nw7kbyUQ@mail.gmail.com> <999247165.134927.1741773596827@195.98.208.36>
Received: via spool by 1633-submit@bugs.x2go.org id=B1633.17440266862532475
          (code B ref 1633); Mon, 07 Apr 2025 11:55:01 +0000
Received: (at 1633) by bugs.x2go.org; 7 Apr 2025 11:51:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_BLOCKED,
	RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED,
	RCVD_IN_ZEN_BLOCKED_OPENDNS,SPF_HELO_NONE,URIBL_BLOCKED,
	URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham
	autolearn_force=no version=3.4.4
Received: from out2.mail.core1.p4.net (out2.mail.core1.p4.net [195.98.222.229])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 91CBC5DA8D
	for <1633@bugs.x2go.org>; Mon,  7 Apr 2025 13:51:20 +0200 (CEST)
Received: from relay2.mail.core1.p4.net (relay2.mail.core1.p4.net [195.98.222.167])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by out2.mail.core1.p4.net (Postfix) with ESMTPS id 4ZWSGc2GC2z7sdQ
	for <1633@bugs.x2go.org>; Mon,  7 Apr 2025 13:51:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leberrohstoffe.com;
	s=s1-p4; t=1744026680; x=1747050680;
	bh=w9v4zqG3ttxrgKlc83Q3UOnL0n3DFTnAb5tjXA8jDcc=;
	h=Date:From:To:Message-ID:Subject:From;
	b=trqgLY+yrBbxxpCeXNvlMzvQI47watJlTW/VEj7qqp8SeV148c8a22upPCwZzv0a/
	 4e6rXsiN4mgC/VB4uZiWgUKx7qxlfuDcGqtY8HqBHWfTHJ43se0pBx+d5uRtRTybuQ
	 6S+kRVb474HZxWhbfCart93KIceCDGzrDbSICgj9HPJzl9cPV9qFxJRWd6yovdDyyX
	 dW1JeKK1EKCSbJzkDVzcjQHU3hRFcLzc3+KYZyGqgotWriV5F3q3Ryh9HxYSK/9tv5
	 s+5KdxUjADTRgxESXwBM9X+22gP77RX1Z8V1DWg+HuE8ecVNrV8+4xv+wfajD3L2Cl
	 f90SHOYtgYg5w==
Received: from relay2.mail.core1.p4.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by relay2.mail.core1.p4.net (Postfix) with ESMTPS id 4ZWSGc1D2Nz10qr
	for <1633@bugs.x2go.org>; Mon,  7 Apr 2025 13:51:20 +0200 (CEST)
Received: from ares-mda1.core1.p4.net (ares-mda1.core1.p4.net [195.98.222.164])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by relay2.mail.core1.p4.net (Postfix) with ESMTPS id 4ZWSGc0nFDzyQ3
	for <1633@bugs.x2go.org>; Mon,  7 Apr 2025 13:51:20 +0200 (CEST)
Received: from 127.0.0.1 (helo=localhost.localdomain)
	by ares-mda1.core1.p4.net with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256)
	id 1u1l0a-000f7N-0r; Mon, 07 Apr 2025 13:51:20 +0200
Date: Mon, 7 Apr 2025 13:51:19 +0200 (CEST)
From: Jens Reyer <jens.reyer@leberrohstoffe.com>
To: 1633@bugs.x2go.org
Message-ID: <1522497032.175025.1744026679855@195.98.208.36>
In-Reply-To: <CANVnVYK4U9eqw59E7aYiLA-58D_aXNTJ1Fh961-OP5Nw7kbyUQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_175023_2042375858.1744026679840"
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.8.2-Rev11
X-Originating-Client: open-xchange-appsuite

[Message part 1 (text/plain, inline)]

Hi Uli,

Attached a new session.log without any ibus mentioning - still the same issue: only the first copy and then every second copy succeed.

For this I uninstalled ibus on both client and server. The session.log is from starting a terminal, then "libreoffice --calc /home/localadmin/test.ods" and then 7 ctrl+c / ctrl+v.

About the setup:

Client (PC, Linux Mint 22.1, twm) and server (Proxmox VM, Debian trixie/sid (testing/unstable), twm, libreoffice 25.2.2.2) are on the same 1Gbit LAN. For testing so far I changed all mentioned characteristics for both server and client (PC/VM, Linux Mint 22/22.1 / Debian, Gnome/Mate/Windows (client)/twm, LAN/VDSL). Using a PC as server or local session helps a bit.

So in my setup the relevant factor is Libreoffice 24 or above (last known good version was Libreoffice 7.3.7) in a x2go session with clipboard client to server enabled.

Greets
Jens


> 
>     Ulrich Sibiller <ulrich.sibiller@gmail.com> hat am 4. April 2025 um 00:17 geschrieben:
> 
>     Hi,
> 
>     I have not fully understood yet what's going with your setup and will
>     go on with checking.
> 
>     However, I see ibus-related communication which I do not see on my
>     setup. I have no experience with ibus or X input methods in general. I
>     see ibus working with selections and _maybe_ it triggers a bug in my
>     code that has been undetected yet. I would like to ask you to repeat
>     testing after disabling/uninstalling ibus. I am wondering if you
>     installed that on purpose or not.
> 
>     Uli
> 
>     On Wed, Mar 26, 2025 at 10:55 PM Ulrich Sibiller
> 
>     <ulrich.sibiller@gmail.com> wrote:
>     >
> 
>         > > 
> >         thanks, review will take some time....
> > 
> >         Uli
> > 
> >         On Tue, Mar 25, 2025 at 12:00 PM Jens Reyer
> > 
> >         <jens.reyer@leberrohstoffe.com> wrote:
> >         >
> > 
> >             > > > 
> > >             Hi
> > > 
> > >             sorry for the late reply. I made my answers inline:
> > > 
> > >             Ulrich Sibiller <ulrich.sibiller@gmail.com> 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
> > > 
> > >             _______________________________________________
> > >             x2go-dev mailing list
> > >             x2go-dev@lists.x2go.org
> > >             https://lists.x2go.org/listinfo/x2go-dev
> > > 
> > >         > > 
> >     > 

[Message part 2 (text/html, inline)]

[session.log.2025-04-07_no_ibus.gz (application/x-gzip, attachment)]

Send a report that this bug log contains spam.