vncserver abandons all selections (CLIPBOARD/PRIMARY) when one selection claimed by other process

[smallid]

Describe the bug
Vncserver abandons all selections (CLIPBOARD/PRIMARY) when one of those selections is claimed by another process running on the server. The remaining selection is still owned by vncserver as far as X is concerned, so when any process requests that selection it will hang waiting for a response from vncserver.

For example, if vncserver owns both CLIPBOARD and PRIMARY and another process claims PRIMARY, then when any process requests CLIPBOARD it will not get a response from vncserver with the data.

To Reproduce
Steps to reproduce the behavior:

1. run vncconfig or use other method to ensure that the primary selection is used to send and receive data (Accept clipboard form viewers, Also set primary selection, Send clipboard to viewers, and Send primary selection to viewers are all set)
2. Copy some data on the machine running VNC client (Ex: copy some text from notepad)
3. Verify data was transferred to selections on the server: xsel -p and xsel -b (primary/clipboard selections respectively)
4. Set primary selection locally on server echo "server data" > xsel -p
5. Attempt to access clipboard selection on server xsel -b
6. xsel command hangs

Note that it is possible to reproduce the issue when Send primary selection to viewers is not set, but the conditions are more limited.

Expected behavior
After step 5. above, xsel should return the data that the vnc server last received from the vnc client. Because the two selections are logically distinct, setting one of them should not invalidate the other.

Client (please complete the following information):

• OS: Windows 10
• VNC client: TightVNC
• VNC client version: 2.8.27
• Client downloaded from: TightVNC web site

Server (please complete the following information):

• OS: Slackware 14.2 x86_64 (post 14.2 -current)
• VNC server: TigerVNC
• VNC server version: 1.10.1
• Server downloaded from: slackware package: tigervnc-1.10.1-x86_64-3
• Server was started using: vncserver

Additional context
This seems like it is caused by vncserver assuming that the clipboard can only hold one piece of information, and I think things generally work when it is only getting/setting the CLIPBOARD selection and not also using the PRIMARY selection.

[CendioOssman]

Unfortunately VNC only has a single clipboard, so keeping something in this case gets messy.

But you seem to be right that we aren't dropping the other clipboard when we lose ownership.

[CendioOssman]

Fixed in 18cc324.

[vityank]

Hey, I suspect that, the fix resolved the sporatious temporary app hang issues, it causes the new one which harms productivity.

Problem description:

1. On server/client AcceptPrimary and SendPrimary are both turned off.
2. Use Windows client.
3. Copy some text on Windows.
   4a) Paste the text into empty space in VNC - Works
   4b) Paste the text into selected space(To rewrite selection) - Nothing -> Primary selection due to text selection cleared up the CLIPBOARD selection.

I need your opinion on this.
Will the following approach fix it or app hangs will return in *Primary=0 mode:
if (vncGetSendPrimary())
DeleteWindowFromAnySelections(pWindow);

I'll soon start testing it on my machine, as currently I only suspect this commit for the problem, and not fully sure yet.

EDIT 1: Built the server and tested - Now works properly(with test fix). Can't yet reproduce the 'hang' effect, so don't know if its present.

[CendioOssman]

You are right, this hampers a common use case (see #1251 as well). Unfortunately the code you suggest will just return the hang. The problem is that the server might not have the data, and the client will likely drop its copy.

A proper fix has been committed as 95ad4d7.

[vityank]

Thanks. While my workaround worked for us quite well(And our apps didn't hang as well) the proper rework is welcome.
I hope to build new version with your fix within upcoming 2 weeks and will report here how it runs.
Thanks again.