Server selection overwrites client clipboard #1896
Comments
|
Hi again, You are right that this would probably be unexpected in some scenarios, like the one you describe. I was likely too quick to close your first issue. Just as you describe, the remote primary selection and the remote regular clipboard are squashed together when syncing with the local clipboard. But I could see a future where the two different clipboards are separately synced with the local counterparts, in cases where the local system also has two different. The more complex question is what to do, when the local system only has one clipboard, like Windows does. For the sake of it, I would like to add a simpler scenario, that illustrates the problem with the two clipboards being squashed:
People used to Windows would probably expect the text from step 1 to be pasted, but that is not what happens. Rather, the text selected in step 3 is pasted, which might be more in line with what Linux-people would expect. |
|
For your use case, you can try to disable sending the primary selection to the viewers. Does that make things behave like you want? vncconfig has an option for this. |
CendioOssman
changed the title
|
Hello @samhed, thank you for your feedback. It is exactly how you write in your simpler scenario (just selecting a remote test "overwrites" local clipboard), but I don't agree with you that linux people would expect that. I'd rather say it is just how tigervnc (haven't checked the other vnc solutions, maybe some other do it the same way, but it doesn't change my opinion about that) behaves at the moment. Why? If you take exactly the same example (your scenario as above), but skip step 2 and just select some other text locally in step 3, in normal circumstances (select "paste" in application menu or in right click popup menu or CTRL-V paste or SHIFT-INS paste) text from step 1 is still pasted in step 4 (as I would expect). Only in case of the middle mouse click, selected text from step 3 is pasted (which I actually never use, and don't consider a standard paste or normal paste anyhow). I've checked the behavior in Pluma (Mate Desktop text editor) as well as in Gnome Text Editor and in terminal (CTRL-V doesn't do nothing there though). About squashing clipboard and primary selection together, for me the only logical choice would be to ignore primary selection if any side doesn't support it. At least by default. If one would prefer a clipboard content and primary selection to interfere, I would resolve that with configuration options, but default should probably still remain to separate those. This way, everything would be the closest to a local behavior (which is not at the moment, as I've tried to describe above). Thank you for your tip about Hello @CendioOssman, |
|
I understand your point of view. I don't know how common the pattern of select-then-paste is, when replacing some text. I suspect there is no real way of knowing what most people expect. One thing that is important to keep in mind here though, is that TigerVNC has worked like it currently does for a long time. We should be extra careful with any changes to the default behavior, even if we add options. |
|
There are cases when you can not (easily) avoid it - like when you create a new document / directory in caja (mate desktop) - a just created file / directory is named "new file" / "untitled folder", and already selected (to be easily named accoding to your preference). Imagine you need to create the same file on 3 remote desktops now. You could easily just paste the new name (copied the first time you type it), but you can not, as "new file" is pasted on the 2nd and 3rd deskop instead... Or, even more common - there is some config file with an option for which you need to change (replace) the value. You change it, and copy the new value to your clipboard on the 1st remote desktop (or, local desktop). But, as soon as you are on the 2nd remote desktop, you need to select the text at the same option first (to paste / replace the value), but at that moment, your clipboard content for the next remote desktop is already gone... I think there is a reason why clipboard and primary selection behave on local system as thy are, each of them. And, users should probably expect the same results for the same actions no matter weather text is local or remote. I would just expect that there would not be a different logic about that, weather the next window is local or remote, that's all... You are right that tigervnc behaves like that for quite some time now. I believe I've reported a similar issue for the first time already in May 2021 (#1251). I'm quite confident that before the beginning of 2021 clipboard behaved as I expect, because I would complain even earlier if I would notice it (I've been doing similar things since about 2005 at least, and don't remember to have such issues before...). Later, I've filled the issue #1615 in March 2023, and believe it has been more or less about that (but I've misunderstand what is going on at that time) as well. And those 2 issues now. So, yes, it has quite some beard already... ;-) |
Describe the bug
If the text is copied from a local machine, and pasted to the first remote machine - overwriting some other text - the clipboard content seem to change and - instead of locally copied text - the text which has just been overwritten on the first remote machine (Primary selection) is pasted into the second remote machine after (instead of a clipboard content, which should still be the content copied from the local machine).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect the same text just copied from from the local machine will be pasted on the 1st and on the 2nd remote desktop, as nothing has to be copied to the clipboard in between.
It is interesting that pasting in some other text editor window on the same (1st) remote machine after step 3 (step 5 above) works as expected (text 'AAA' is actually pasted, so clipboard content on this remote machine is not overridden by a Primary selection), but pasting on another remote machine (step 4) results in Primary selection from the 1st remote machine is pasted there instead of the clipboard content.
So, something is obviously wrong somewhere, as I would expect a consistent behavior - the same text to be pasted after step 3 in another text editor window (or terminal or any other application) in 1st and on the 2nd remote desktop, what is obviously not the case. After that, it can be a subject of discussion if the right click paste should result in Primary selection to be pasted instead of a clipboard content or not, if one believes this would be better / more reasonable...
Client (please complete the following information):
Server (please complete the following information):
Additional context
I am sorry to bother, this is the same (hopefully more clear) report of a - for me very annoying - issue #1889, which has been reported already and closed (and was not reopened despite I've asked @samhed - who closed it - to reopen it as he obviously still misunderstands my point and consider the reported behavior as expected).
I'd ask @CendioOssman to take a look on that before one of you close this issue as well. I hope you will understand that obiously a Primary selection is somehow overriding a copied clipboard content between remote vnc desktops in a way I wouldn't expect (I never use a Primary selection and never had such issues in any local environment, and don't remember to see this behavior in vnc before some years ago...).
A very similar bug has been present in the past (just the selected text on the remote machine to be overwritten has been pasted instead of text copied into the clipboard on the local machine, if I remember well). This seem to be a kind of reincarnation of that one...
The text was updated successfully, but these errors were encountered: