On Fri, Aug 10, 2018 at 9:42 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 10.08.2018 um 09:25 schrieb Walid MOGHRABI:
For what I can tell, this only happens with the Windows client, even the latest one. I have never been able to reproduce it with the Linux client and I don't use the Mac client so I can't tell.
As someone already said, pretty hard to reproduce, don't happen very often but often enough to be annoying.
This is interesting. Uli made a change in the code a while ago (either for the March 2018 release or even before, I don't remember) that should have fixed this. I haven't had the issue myself since then, though I'm not using Windows as often as I used to.
IIRC that fix is from August 2016. It fixed https://bugs.x2go.org/952
However, that relied to the first paste right after session start. The description above mentions problems DURING a running session.
I don't know what is happening there but maybe using these hints you can mitigate the problem:
- we currently only support 256kb maximum clipboard size. Bigger clipboards will cause problems (we do not support the so-called INCR mode for clipboard handling). So please limit yourself to smaller selections.
- do not use a clipboard manager inside or outside the session
- on Linux you have (at least) two clipboards, so in case of problems it might happen that you just reference the wrong one (middle mouse vs. paste from the menu)
- konsole for example has own code to synchronize the two clipboards. Might interfere with NXs logic
- I sometimes see this with rdp session inside an NX session. It usually helps to mark something in windows and copy it. Afterwards you can copy/paste from the outside again
- ensure that the XFIXES extension is activated
Unfortunately the clipboard code is not easily understood and debugging is quite cumbersome because you have so many parties involved.
So if someone can come up with a sure way to trigger the behaviour we might be able to properly debug it.
Uli