The following scenario currently doesn't work in ThinLinc: 1. Copy some text on the client 2. Select some text on the server you want to replace 3. Try to paste your new text (e.g. Ctrl+V, or toolbar button) The user would expect the selected text to be replaced with the copied text, but instead nothing happens. To make things worse if you paste a few times out of frustration, all of those attempts will succeed if you go back to a client application and copy some new data. This was reported upstream: https://github.com/TigerVNC/tigervnc/issues/1251 The report there also claims it is a regression. It could be because of bug 3895.
I can confirm this happens on 4.12.1, but not on 4.11.0. So this is indeed a recent regression. Tested on RHEL 8 with GNOME and gedit.
This unfortunately doesn't seem to be possible to solve without losing some of the benefits of the new clipboard model. The problem is that the new model is a pull model, whilst the older was a push based model. That means the server doesn't have the clipboard data until an application actually needs it, whilst before we were always forced to cache the data in case someone needed it. So the new model is much more efficient since no data is transferred if it's never needed. The reason things go wrong here is because the new protocol, like the old one, doesn't have the concept of multiple clipboards. So when one of the clipboards on the server changes we tell the client of this fact. This means we have to assume we can no longer request the (previous) clipboard data from the client as it was likely lost once the client took possession of the local clipboard. So if a server applications requests the _other_ clipboard, which the server still claims to own, then we have no way of delivering on that promise as the data is gone. It seems this scenario was already considered as we have code that tries to drop ownership of any secondary clipboards once we lose ownership of one of them. For some reason that isn't working as we're still getting requests from clients. The only way I can see to solve this is to make sure we have a copy of the data, in case an application asks for it in the future. This means we start transferring data needlessly though, which is a clear downside. We can probably minimise the cost by only transferring the data when this scenario might happen. I.e. when we lose one of the clipboards but still own the other one. Unfortunately this scenario is probably common as the selection clipboard is regularly changed.
Also note that we are way behind upstream so we'll have to backport a fix here.
Upstream fix: https://github.com/TigerVNC/tigervnc/commit/95ad4d70925c65ac3c90a10df5a4bf00ad22d90d
Works well now. Tested between two firefox instances, client Fedora 33 and server Ubuntu 20.04.
The regression was reproduced in 4.12.1. Tested using Jenkins server build #2244 running on Fedora 33 with a client and the 4.13.0 beta clients running on Fedora 33, macOS, and Windows 10. - [4/4] Copying text from a local application to a remote session - [X] Using C-c and C-v - [X] Using mouse selection and middle-mouse-button (Linux client only) - [X] Using mouse selection and C-v (Linux client only) - [X] C-c C-v, overwriting selected text in the remote session (as described in comment 0) - [3/3] Copying text from a remote session to a local application - [X] Using C-c and C-v - [X] Using mouse selection and middle-mouse-button (Linux client only) - [X] Using mouse selection and C-v - [X] Release notes
