Bug 7712 - Select and paste doesn't work in to session
Summary: Select and paste doesn't work in to session
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Pierre Ossman
Keywords: relnotes, wilsj_tester
Depends on:
Reported: 2021-05-19 17:00 CEST by Pierre Ossman
Modified: 2021-08-11 12:50 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2021-05-19 17:00:16 CEST
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:


The report there also claims it is a regression. It could be because of bug 3895.
Comment 1 Pierre Ossman cendio 2021-05-20 09:35:30 CEST
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.
Comment 2 Pierre Ossman cendio 2021-07-21 08:42:24 CEST
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.
Comment 3 Pierre Ossman cendio 2021-07-21 08:43:04 CEST
Also note that we are way behind upstream so we'll have to backport a fix here.
Comment 6 Pierre Ossman cendio 2021-07-21 10:33:49 CEST
Works well now. Tested between two firefox instances, client Fedora 33 and server Ubuntu 20.04.
Comment 7 William Sjöblom cendio 2021-08-11 12:50:38 CEST
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

Note You need to log in before you can comment on or make changes to this bug.