clipboard direction restrictions: client to server only, server to client only

[totaam]

It may be useful to provide a way of doing that.

VirtualBox does this for example.

Maybe:

--clipboard=[copy|paste|both|off|disabled]

So each end can limit what it will support.

And a toggle at runtime via the tray menu (as long as it is not 'disabled').

[totaam]

2016-04-24 13:32:06: L29Ah commented

---

Actually it would be awesome to make it switchable with xpra control.

[totaam]

2016-04-24 13:37:55: L29Ah commented

---

Er, no, that wouldn't be very secure. Via a key-shortcut then.

[totaam]

How is a key shortcut more secure than the control channel?
The control channel can be made to require authentication, key presses are trivial to inject into any local X11 application.

[totaam]

2016-04-24 19:18:03: L29Ah commented

---

Replying to [comment:5 antoine]:

How is a key shortcut more secure than the control channel?
The control channel can be made to require authentication, key presses are trivial to inject into any local X11 application.

Never mind, they are both needed and security depends on the use case. In my case the server runs in the unsafe environment, so its actions cannot be relied upon; it sure can be otherwise, although it looks strange from my point of view.

[totaam]

2016-05-30 07:07:13: antoine uploaded file clipboard-directions.patch (38.1 KiB)

mostly complete patch

[totaam]

Implemented in r12709: use clipboard-direction=to-server|to-client|both|disabled.
Can also be toggled from the systray, as of r12711 via xpra control or the server dbus interface (#904).

@l29ah: does this work for you?

[totaam]

2016-05-31 23:09:45: L29Ah commented

---

Tried to build trunk:

clang -O2 -pipe -O2 -pipe -march=native -fno-strict-aliasing -fPIC -I/usr/include/python2.7 -c xpra/x11/bindings/wait_for_x_server.c -o /var/tmp/paludis/x11-wm-xpra-9999/work/xpra-9999-python2_7/temp.linux-x86_64-2.7/xpra/x11/bindings/wait_for_x_server.o -Wall -Werror -Wno-unneeded-internal-declaration -Wno-unknown-attributes -Wno-unused-function -Wno-sometimes-uninitialized
In file included from xpra/x11/bindings/wait_for_x_server.c:26:
In file included from /usr/include/python2.7/Python.h:126:
/usr/include/python2.7/modsupport.h:27:65: error: 'format' attribute argument not supported: _PyArg_ParseTuple_SizeT [-Werror,-Wignored-attributes]
PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);
                                                                ^
/usr/include/python2.7/pyport.h:908:57: note: expanded from macro 'Py_FORMAT_PARSETUPLE'
#define Py_FORMAT_PARSETUPLE(func,p1,p2) __attribute__((format(func,p1,p2)))
                                                        ^
1 error generated.

[totaam]

@l29ah: this looks like a toolchain issue, please file a separate ticket for that.
Alternatively, there should be recent beta builds with this change here: https://xpra.org/beta

[totaam]

2016-06-02 12:45:58: L29Ah commented

---

Stripped away -Werror, got this:

(EE) 
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)

Even though /dev/tty0 is there:

crw--w---- 1 root tty 4, 0 май 19 19:59 /dev/tty0

[totaam]

Those compilation errors are unrelated to this ticket, please use a separate ticket and include the full error.
Looks like your xvfb option is not configured properly. If you are on Ubuntu, you need to build with --without-Xdummy.

[totaam]

@afarr: you may be interested in this feature (ignore comment:7 onwards which have nothing to do with this)

[totaam]

2016-10-01 01:57:04: afarr commented

---

Was expecting to just do a quick test, 1.0 13937 osx client, 1.0 r13912 fedora 23 server... but I seem to be running into issues when trying to use the control channel to set clipboard direction.

• With either xpra control :13 clipboard-direction to-server or xpra control :13 clipboard-direction to-client, I get an error code 127 in the ssh shell in which I try to send the command:

server returned error code 127
 error processing control command: 'XpraServer' object has no attribute 'client'

Interestingly, I get the same message about no attribute 'client' whether I'm trying to set "to-client" or "to-server".

The server logs are more verbose with the problem:

2016-09-30 16:45:02,914 error processing control command 'clipboard-direction'
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 1037, in process_control_command
    v = command.run(*args[1:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/control_command.py", line 67, in run
    return super(ArgsControlCommand, self).run(*args)
  File "/usr/lib64/python2.7/site-packages/xpra/server/control_command.py", line 32, in run
    return self.do_run(*args)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 1699, in control_command_clipboard_direction
    self.client.clipboard_helper.set_direction(can_send, can_receive)
AttributeError: 'XpraServer' object has no attribute 'client'

• Likewise, when I try to use d-feet to run the setClipboardDirection dbus command... when I enter to-server I get a "name 'to' is not defined" message and, of course, entering server produces a "name 'server' is not defined" message.

• With a --clipboard-direction=to-server set client-side upon connection, I notice no effect, and using the "application menu -> xpra -> clipboard -> clipboard/server to client only" tray-like option of the osx client to try to set the value on the fly (clipboard seems to be working in all directions despite use of the client-side flag) seems to produce absolutely no change.

Using the same --clipboard-direction=to-server as a server flag does produce a warning for the client about the clipboard direction limits, but rather than just limiting clipboard functionality to copies client-side syncing and being pastable to server session... it looks like the clipboard (clipboard clipboard, if you will) begins failing to sync at all in either direction after any contents are copied on the client-side; with selections copied server-side pasting server side, while selections pasted client-side are pasting client-side... and never the twain do meet (got logs of this behavior, with outline of what steps I logged below).

--clipboard-direction=to-client seems to work as expected, though it also can't be changed on the fly.

Ran a test with -d clipboard running both server and client, with --clipboard-direction=to-server... and collected logs which I'll attach. Quick script.

• I copied something client-side, and pasted it successfully "to-server".

• I then copied something server-side and failed to paste it "to-client" (as expected... paste back to-client pasted the contents of the client-side clipboard, un-sync'd by the paste action server-side... i.e. exactly what I'd pasted "to-server" in that first copy/paste) .
• I then copied something else client-side, which failed to paste "to-server" (at this point, the contents that were pasted were exactly what had just been copied server-side, and then failed to paste "to-client" in the previous (second star) step... indicating that, after having blocked to sync of the clipboard clipboard server-side upon the copying/updating of new contents client-side (second star), further copying server-side likewise begins failing to sync contents to client-side clipboard (at which point, neither side is sync'ing, and the behavior has gone from "to-server" to "disabled" - third star).

[totaam]

2016-10-01 01:58:17: afarr uploaded file xpra-ticket276-to-server-d-clipboard-server-logs.txt (71.3 KiB)

server logs

[totaam]

2016-10-01 01:59:57: afarr uploaded file xpra-ticket276-to-server-on-server_client-log.txt (37.2 KiB)

client side -d clipboard logs

[totaam]

• dbus / xpra control "clipboard-direction": fixed and improved in r13942 (will be added to unit tests I am writing)
• d-feet requires string arguments to be quoted, ie: "to-server"
• the rest is likely to be caused by a clipboard-challenged OS (win32 and even more so for osx) - will take a look

[totaam]

2016-10-05 18:30:32: antoine commented

---

Congratulations on hitting issues I had missed, right on your first attempt!

Lots of fixes:

• OSX clients could still receive server side changes in "to-server" mode, fixed in r13976. Note: when using this clipboard-direction option client-side, the server may still send the clipboard data down the wire to the client, the client will just ignore the data. (will follow up in tell the server about clipboard direction #1329 for a better fix to avoid even sending it)
• OSX clients in "to-client" mode could clear the server-side buffer by copying something into the clipboard (the data would not get copied across however), fixed in r13977
• the state could get wedged when switching the direction of copying and a direction restriction is in place, fixed in r13989 (r13990 for osx), probably explains the "no longer syncs" issue
• OSX clipboard code is "greedy" so we have to send data with the tokens, fixed in r14007

This should also improve compatibility with older clients and server (though that's not guaranteed to work quite as well as before when mixing with older versions and using this flag).
We now also have automated unit tests for the clipboard, including one that tries to mimic the osx clipboard behaviour on Linux. (turning on "want-targets" and "greedy" options). And I have been testing this feature by hand on multiple platforms.

---

That said... I know you're kinda gifted for finding issues, so I'm not promising that we're done here..

If you still find problems with this feature, please try to reduce the scope of the bug hunt by running tests as similar as you can make them to the unit tests:

• using the flag with the client only
• copying in and out with xclip to verify (notepad on win32 / textedit on osx)
• copying in one direction twice then the other way, the back to the original direction

We can worry about the use of the server-side flag, runtime changes via the dbus and control channels, or using the system tray UI to change the settings later. (or any combination of those - which could take forever..)

If you still find any problems with this or with the simple test cases above, please include:

• the exact commands you used, including xclip and steps (as simple as can be)
• the value that was copied across (and make it easy to spot, ie: COPIED_FROM_OSX_CLIENT)
• logs - as small as can be
• whether the bug occurs on other platforms or not (in particular Linux, which is so much easier to test and debug)

[totaam]

2016-12-09 22:49:04: afarr commented

---

Tested some more, using just client-side flags, with OSX 1.0 r14467 and windows 1.0 r14492 client, against 1.0 14502 fedora 23 server.

• With the windows client, all the options are working as hoped, except for the minor issue that with --clipboard-direction=disabled - if something is copied locally it clears the clipboard on the server side. A very minor issue.

There are some odd messages when I try to copy the entire contents, locally, of a 75KB file in order to paste server side:

C:\Program Files (x86)\Xpra\library.zip\xpra\clipboard\clipboard_base.py:717: GtkWarning: gdkselection-win32.c:423: OpenClipboard failed: Access is denied.
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdk_property_delete: assertion `window != NULL' failed
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: inner_clipboard_window_procedure: assertion `success' failed

And the additional messages upon disconnection afterward of:

2016-12-09 11:05:25,966 received console event CTRL_C
2016-12-09 11:05:25,974 sound output stopping
sys.excepthook is missing
lost sys.stderr

The clipboard contents copied and pasted as hoped though.

• With the OSX client, I see the same clearing of the server-side clipboard contents upon copying anything locally with --clipboard-direction=disabled, and I also see an odd message upon starting:

Warning: invalid value for clipboard-direction: 'disabled'
 specify 'to-server', 'to-client' or 'both'

Unfortunately, with the --clipboard-direction=both, after copying anything server side, further copying locally fails to sync to the server-side clipboard (and with -d clipboard running on the server, there is no indication of anything happening when doing further copying locally... and likewise the contents of the gtk_view_clipboard tool don't update with new contents after a local copy).

Even more unfortunately, it looks like that same behavior is seen when using the default value of 'both'... so if I don't use any clipboard-direction flag with the OSX client, once I copy something on the server, I can no longer sync local copying with the server clipboard(s).

That's a problem.

Easy repro.

• Connect OSX client.

• Using a browser, or even just gedit, copy something on the server-side.
• Copy something else client side & try to paste server side.

Whatever the contents were of that first copy server side is what will paste.

I'll attach some short logs from both server and client side... following the above steps with a gedit window prepared in advance with contents of "server-side-content", after the copying of which I copied "client-side-content" from a textedit window, then tried to paste that back into the server-side gedit window (and got a second copy of "server-side-content".

Since I didn't even have to bother with the client side flags to trigger this, I'm going to raise the Priority.

[totaam]

2016-12-09 22:58:24: afarr uploaded file ticket276_server-logs-d-clipboard_with-client-remote-logs-included.txt (34.7 KiB)

server -d clipboard logs with bonus client remote logging logs for same, with same

[totaam]

r14641 fixes the spurious invalid value for clipboard-direction warning. "disabled" is a valid option.

With r14638 + r14642, we're now back to the same code as r13977... Which means we should not be clearing the server side value when "disabled" is used and OSX clients should get the new value if the server side value is changed.
I hope this doesn't break some other use case!

[totaam]

(raising as I would like to include this in 1.0.1)

[totaam]

Taking this back: I believe this causes a clipboard loop on Linux.
It even causes the whole client to deadlock following the message clipboard toggled to off by the server, reason given: more than 20 clipboard requests per second!

[totaam]

Fix in r14704 for the deadlocks, already backported.
(useful fix for an existing deadlock pattern which just occured more readily with the attempt at a fix for the osx clipboard)

But the OSX clipboard is still not syncing properly (as per comment:16).

[totaam]

2017-01-07 09:43:12: antoine commented

---

r14720 fixes a bug where syncing would stop with osx clients, 14722 adapts it to v1.0.x to prevent sync loops.

I have published 1.0.1 with this change... so I hope I haven't missed anything critical.

I think #1400 will be useful, especially if osx clients sync with PRIMARY.

[totaam]

2017-01-11 18:55:40: afarr commented

---

Did some quick tests with 1.0.1 14723 osx client (from dists) against a 1.0.1 r14570 fedora 23 server.

As mentioned above, looks like OSX clipboard is still not sync'ing correctly, but otherwise behavior seems the same - though I'm not sure how to induce the sync loops that you mentioned (I think I know which ones you mean, but I've never been able to reliably repro them).

In any case, the work in 14722 doesn't seem to have caused any regressions.

I'll hand this back to you pending inspiration on sync'ing the clipboards the rest of the way.

[totaam]

2017-01-12 05:46:41: antoine commented

---

14765 applies the fix to the 1.0.x branch, it's been in trunk long enough and I haven't seen any negative side effects. But maybe you will?

New OSX beta 1.0.2 build uploaded.

[totaam]

2017-01-16 23:53:51: maxmylyn commented

---

Using a Fedora 25 14799 1.X server with a Windows 8.1 14780 1.X client I am getting periodic clipboard crashes. Just copying and pasting is enough to cause the whole server to stop responding.

On the client side I get this traceback most of the time (1/5 times I didn't get it):

C:\Program Files (x86)\Xpra\library.zip\xpra\clipboard\clipboard_base.py:600: GtkWarning: gdk_property_change: assertion
 `type != GDK_TARGET_STRING' failed
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdkgc-win32.c:830: SaveDC failed: T
he operation completed successfully.
C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:383: GtkWarning: gdkgc-win32.c:970: RestoreDC failed
: The operation completed successfully.
pnc=: T2017-01-16 15:35:07,047 sound output stopping

And one time on the server I got this print:

Our peer requested the contents of the clipboard, but *I* thought *they* had it... weird.

---

Will retry with -d clipboard.

edit: After mentioning this to afarr - he suggested commenting here.

[totaam]

2017-01-17 00:29:31: maxmylyn commented

---

Hmmmm looks to be easily triggered by using start-desktop with a --start-child=startlxde with LXDE installed - LXDE seems to be spamming the clipboard with small copies to the point that the clipboard breaks.

I see this being spammed in the server side logs:

2017-01-16 19:10:54,507 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,721 clipboard: CLIPBOARD owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: CLIPBOARD owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2017-01-16 19:10:54,722 clipboard: PRIMARY owner_changed, enabled=False, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False

[totaam]

2017-01-17 16:04:29: antoine changed owner from afarr to maxmylyn

[totaam]

2017-01-17 16:04:29: antoine commented

---

Let's ignore the lxde problem from comment:26 for now, lxde starts a clipboard manager by default - which is bound to cause problems.

Is the problem you are reporting in comment:25 a regression in 1.0.1 from 1.0?
What do I need to do to reproduce it? I can't get it to misbehave that badly. Do you have logs?

[totaam]

2017-01-18 18:59:44: maxmylyn changed owner from maxmylyn to alas

[totaam]

2017-04-18 01:53:09: afarr commented

---

Well, I made some time, but found that some shared systems needed some tinkering to set back up. Will test this soon... but failed this time.

[totaam]

2017-04-25 19:23:55: maxmylyn changed owner from alas to antoine

[totaam]

2017-04-25 19:23:55: maxmylyn commented

---

Using a 1.X r15617 Client and Server - both machines running Fedora 25:

• Changing the clipboard mode out of both using the control channel or tray works fine - it limits directions.

That being said, starting a server with --clipboard-direction=to-server seems to have no effect, until I try to change the direction using the tray.

I'll get some logs in a second.

[totaam]

2017-04-25 22:05:48: maxmylyn commented

---

Okay I figured it out. Only to-server was the problem - I accidentally hit up one too many times and started with to-client.

edit: forgot to change tense.

However, when trying to get logs using the following steps:

• On client, I have Gedit open in the background with a couple lines of random text - on the server I have Firefox set to open up by default, which goes to the Fedora homepage.

• I'll connect, highlight something, then copy and paste it in to the URL bar.

• Then I'll highlight something on the webpage and paste it locally into Gedit.

It was broken both directions. When doing the to-server part, I could copy both ways from the get-go. When doing the to-client, the clipboard didn't work at all and updated the local and remote ones separately.

Using the --clipboard-direction flag causes some serious clipboard instability. Sometimes it works fine (usually with to-server), sometimes it breaks horribly.

Either way, I'll post the logs I got.

[totaam]

2017-04-25 22:07:40: maxmylyn uploaded file 276clientdclipboardtoclient.txt (30.5 KiB)

client side logs with --clipboard-direction=to-client

[totaam]

2017-04-25 22:07:55: maxmylyn uploaded file 276clientdclipboardtoserver.txt (4.8 KiB)

client side logs with --clipboard-direction=to-server

[totaam]

2017-04-25 22:08:13: maxmylyn uploaded file 276dclipboardtoclient.txt (80.4 KiB)

server side logs with --clipboard-direction=to-client

[totaam]

2017-04-25 22:08:28: maxmylyn uploaded file 276dclipboardtoserver.txt (15.5 KiB)

server side logs with --clipboard-direction=to-server

[totaam]

2017-04-26 19:13:29: antoine commented

---

Okay I figured it out. Only to-server was the problem - I accidentally hit up one too many times and started with to-client.
I guess this means I can safely ignore comment:31 and comment:32?

It was broken both directions. When doing the to-server part, I could copy both ways from the get-go. When doing the to-client, the clipboard didn't work at all and updated the local and remote ones separately.
I am unable to reproduce any of those problems, I've tried with both the 1.0.x branch and trunk. Repeatedly.

Please document the exact command lines that you've used.
It is much easier to reproduce reliably using "xclip" commands rather than relying on descriptions of the steps using a heavyweight application like firefox. (which is also known for having its own clipboard quirks)

Using the --clipboard-direction flag causes some serious clipboard instability. Sometimes it works fine (usually with to-server), sometimes it breaks horribly.
Please define "instability" and "breaks horribly". Did it eat some kittens?

---

Here's an example of my test results with "to-client":

xpra start -d clipboard :100
xpra attach -d clipboard :100 --clipboard-direction=to-client
echo "set client clipboard to a known value" | xclip -i -selection CLIPBOARD
#verify that there is no data in the server clipboard:
DISPLAY=:100 xclip -o -selection CLIPBOARD
Error: target STRING not available
#set a value:
echo "server value" | DISPLAY=":100" xclip -i -selection CLIPBOARD
#verify it is set on the server:
DISPLAY=:100 xclip -o -selection CLIPBOARD
#and now also on the client:
xclip -o -selection CLIPBOARD
#change the client value:
echo "new client value" | xclip -i -selection CLIPBOARD
#verify that the server value has not changed:
DISPLAY=:100 xclip -o -selection CLIPBOARD

If you get unexpected results following a scenario like this one, grab the log samples of just when the problem occurs.
If you don't, then we'll know that the problem requires a more specific setup / command-line / options / client application etc. Then you can tweak until the problem occurs.

[totaam]

2017-04-29 00:19:23: maxmylyn commented

---

I guess this means I can safely ignore comment:31 and comment:32?
[[br]]

Yes.

[[br]]

Please document the exact command lines that you've used.

[[br]]

For server start I used xpra start :13 --bind-tcp=0.0.0.0: --start-child=xterm --start-child=firefox --clipboard-direction=to-client/to-server, and I connected with xpra attach tcp:ip -d clipboard.

[[br]]

Please define "instability" and "breaks horribly". Did it eat some kittens?

[[br]]

My bad, I forgot to explain. When I said instability and breaks, I meant that sometimes it works fine, and other times it breaks completely. By breaks horribly I mean that it'll either not respect direction, or it'll break clipboard sync entirely, and I'll end up with the server and the client with separate clipboards entirely.

---

Moving along, I still don't follow the xclip commands, despite having stared at them for a few hours today. I'll follow up with them on Tuesday.

[totaam]

2017-04-29 20:27:45: dragon788 commented

---

maxmylyn, maybe this will help break down the xclip for you? https://explainshell.com/explain?cmd=DISPLAY%3D%3A100+xclip+-o+-selection+CLIPBOARD

Basically the -i/-o is "in" or "out", aka stdin (to xclip) or stdout (from xclip). By starting xpra with the clipboard "bound" to display :100, when you call xclip with DISPLAY=:100 (there is also a --display option iirc) it targets the xpra session rather than local. When it was called without DISPLAY=:100 it is then showing your current local client clipboard to show that it was a one way sync.

[totaam]

2017-05-04 21:11:28: maxmylyn commented

---

@dragon788 - thanks for that, that makes a lot of sense.

@antoine:

Okay I followed the steps you mentioned in comment:34 and it's working fine. And, using the --clipboard-direction= from the client side seems to also be working just fine with r15794.

Keeping in mind using a more lightweight application, I decided to start my server using xpra start :13 --bind-tcp=0.0.0.0: --start-child=xfce4-terminal --clipboard-direction= -d clipboard. Using --clipboard-direction= from the server side is where I seem to be running into some trouble. Setting it to --clipboard-direction=to-server as a part of the server start command broke my clipboard sync entirely about 40-50% of the time (tested several times), in which case the clipboard didn't sync at all and I ended up with two clipboards (remote and local). However, using --clipboard-sync=to-client works fine - it didn't break the clipboard at all, even after several sessions.

[totaam]

2017-05-05 07:38:18: antoine commented

---

So the only problem is with to-server set on the server?
When you say it breaks 40% or 50% of the time, is this initially or after some events?
Could this be timing related? Does the type of client matter?
Do you have minimal logs comparing the working and non-working case?

[totaam]

2017-05-09 17:34:10: maxmylyn commented

---

Amazingly I got it to break sync on the first try. I started the server with xpra start :13 --start-child=xfce4-terminal --bind-tcp=0.0.0.0: --clipboard-direction=to-server --no-daemon -d clipboard > /home/max/276brokenclipboard.txt 2>&1 and connected. On this connect, clipboard did not work in either direction - tested using gedit on my local machine and xfce4-terminal on the remote machine.

I'll try getting a log sample of it working as expected.

[totaam]

2017-05-09 17:35:06: maxmylyn uploaded file 276brokenclipboard.txt (16.5 KiB)

-d clipboard logs of broken clipboard sync - serverside

[totaam]

2017-05-09 17:35:20: maxmylyn uploaded file 276clientbrokenclipboard.txt (4.8 KiB)

-d clipboard logs of broken clipboard sync - client side

[totaam]

2017-05-09 17:38:00: maxmylyn uploaded file 276workingclipboard.txt (22.9 KiB)

Serverside logs of working clipboard restriction

[totaam]

2017-05-09 17:38:51: maxmylyn uploaded file 276clientworkingclipboard.txt (10.2 KiB)

client side logs of working clipboard restriction

[totaam]

2017-05-10 15:06:33: antoine commented

---

Much more reliable steps to reproduce the problem:

#set clipboard value on client:
echo foo | xclip -i -selection CLIPBOARD
#verify the server has synced it:
DISPLAY=:100 xclip -o -selection CLIPBOARD
#change the value on the server:
echo bar | DISPLAY=:100 xclip -i -selection CLIPBOARD
#verify that the client has not synced it:
xclip -o -selection CLIPBOARD
#set a new clipboard value on client:
echo foo-again | xclip -i -selection CLIPBOARD
#show the server clipboard value:
DISPLAY=:100 xclip -o -selection CLIPBOARD

At this point the server still has the old "bar" value, because it hasn't sent the token to the client when the value changed to "bar", and so the client can't sent the token back when its value changed to "foo-again".

r15799 fixes this. This is scheduled for the next 1.0 update, please check that this fixes your problem and that it doesn't cause any regressions.

[totaam]

2017-05-12 17:42:30: maxmylyn commented

---

A quick sanity test has concluded that it fixed the specific issue I found. I'll take a few minutes now and make sure no regressions came up. I'll likely close this in an hour or so.

[totaam]

2017-05-13 04:54:03: antoine commented

---

Thanks, fix backported in 15820.

[totaam]

2017-05-16 17:53:54: maxmylyn commented

---

Alright I took a few minutes out of this morning to double check - and r15799 fixes the specific issue I found. As far as I can tell it doesn't break any other clipboard functions(double checked both direction limitations, disabled copmletely, along with no restrictions), so I'm going to finally close this ticket at long last.

Cheers.