Xpra: Ticket #275: handle clipboard large data transfers better

At present, the limit for clipboard packets is 32KB (see #274), which means that:

Solutions:



Thu, 28 Feb 2013 10:42:45 GMT - Antoine Martin: status, description changed


Thu, 28 Feb 2013 15:36:41 GMT - Antoine Martin: description changed

r2849 builds on r2848 to show to the user that something is happening with the clipboard: we blink the system tray (not on win32 yet) and change it to a clipboard until we receive all the response(s) from the server.

We also bump the clipboard maximum size to 256KB and constify it.


Thu, 28 Feb 2013 16:12:40 GMT - Antoine Martin:

r2850 makes the server tell the client about its pending clipboard requests so we now display the cue no matter which direction the copy+paste operation is from.

Each changeset has details in the commit message - worth a read.


Fri, 22 Mar 2013 13:19:30 GMT - Antoine Martin: owner, status changed

Now that #272 should work, please take a look.


Mon, 25 Mar 2013 21:23:23 GMT - alas: status changed


Tue, 26 Mar 2013 00:53:48 GMT - alas: status changed; resolution set

It looks like the bump to 256 KB makes the clipboard big enough to handle pretty much any reasonable or even not-quite-reasonable amount of text.

Currently the clipboard doesn't seem to support even thumbnail-sized image copying or pasting- but it looks like ticket #273 is aiming at dealing with other formats than text.

I think that can wait for 1.0, so I'll go ahead and close this ticket.


Wed, 22 May 2013 12:48:48 GMT - Antoine Martin:

Unfortunately, this caused a regression on Ubuntu with appindicator installed: #344


Tue, 29 Oct 2013 11:12:00 GMT - Antoine Martin: status, milestone changed; resolution deleted

Re-opening because of #448, enough changes there to need re-testing.

The "blink and show clipboard icon in the system tray" is likely to be disabled for 0.10.x


Tue, 29 Oct 2013 13:39:23 GMT - Antoine Martin: status changed

v0.10.x will no longer change the tray icon and tooltip on clipboard requests as of r4630.

afarr, can you please re-test trunk? (win32, osx, appindicator, etc..) This is related to ticket:318#comment:15


Tue, 29 Oct 2013 22:52:53 GMT - alas:

Testing the clipboard on osx 10.6.8, xpra client 0.11.0-r4630 (our build) with xpra-0.11.0-1.fc19.x86_64.rpm server side (beta release, fully updated fedora19)... the xpra icon no longer "hops", nor does the clipboard icon overlay it when copies are made on the local client machine.

(As a clarification from ticket #318, with the 10.6.8 osx, when the dock was "hidden" then the icon would "hop" into view... when the dock wasn't hidden, the clipboard icon overlaid it... But, after the session was "grabbed" by another client on another local machine, then "re-grabbed" back by the 10.6.8 machine's client... once that "transfer" had taken place, the xpra icon no longer reacted to copying on the local desktop on the 10.6.8 machine. However, with an osx 10.7.5 machine running the same xpra client version ... the clipboard icon overlaid before and after connection "transfers" identically.)

2013-10-29 15:12:52,203 unhandled format 0 for clipboard data type NONE
2013-10-29 15:17:39,788 connection closed after 23K packets received (0.1G bytes) and 7K packets sent (0.2M bytes)
2013-10-29 15:17:39,815 Connection lost

When repeated the second and subsequent error messages indicate fewer packets but the client crash behavior is the same:

2013-10-29 15:18:13,686 unhandled format 0 for clipboard data type NONE
2013-10-29 15:18:13,737 connection closed after 223 packets received (0.8M bytes) and 35 packets sent (11K bytes)
2013-10-29 15:18:13,738 Connection lost

This crash was completely reproducible, but did not impact the server session at all (I was able to re-connect to the continuing session and crash the client anew at will).

Repeating with --opengl=off also results in a client crash with packet numbers similar to the second and subsequent crashes with opengl on.

Using the gtk_view_clipboard.py tool It appears that copies to the clipboard within the xpra session are being recorded to both clipboard and primary, but copies from the local client show no change in the clipboard values (and, as one would expect, there is no change in what is pasted).

As a semi-related note, trying to use the xpra gtk_view_keyboard source (and presumably the view_clipboard as well) inside the Python shell included in the Helpers directory produces an import error:

Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named pygtk
>>>

... despite pygtk being easily (enough) locatable in ...xpra.app/Contents/Resources/lib - a stumbling block that prevents me from checking what might be happening with the clipboard in the local osx environment (though I suppose we can guess about that).


Wed, 30 Oct 2013 02:10:16 GMT - Antoine Martin:

when the dock was "hidden" then the icon would "hop" into view

How do you hide the dock? Do you mean covered by other windows?

once that "transfer" had taken place, the xpra icon no longer reacted to copying on the local desktop on the 10.6.8 machine

Could be related to the same problem as below (lack of AppKit). If not, can you please provide logs with XPRA_CLIPBOARD_DEBUG=1

with this new release copies made on the local desktop are not recognized by the client's session clipboard

Can you clarify which versions/builds work and which ones don't? This could well be related to a missing AppKit.

trying to copy a "relatively" large block of content ... caused the xpra client to crash

This was caused by opportunistic clipboard compression (which only fires on data bigger than 256 bytes) and looked like this in the server log:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 373, in _write_format_thread_loop
    self._add_packet_to_queue(*self._get_packet_cb())
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 384, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 532, in encode
    main_packet, proto_version = self._encoder(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 484, in rencode
    return  rencode_dumps(data), Protocol.FLAGS_RENCODE
  File "rencode.pyx", line 324, in xpra.net.rencode._rencode.dumps (xpra/net/rencode/rencode.c:4019)
  File "rencode.pyx", line 304, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3828)
  File "rencode.pyx", line 244, in xpra.net.rencode._rencode.encode_list (xpra/net/rencode/rencode.c:2841)
  File "rencode.pyx", line 307, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3853)
  File "rencode.pyx", line 256, in xpra.net.rencode._rencode.encode_dict (xpra/net/rencode/rencode.c:3119)
  File "rencode.pyx", line 304, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3828)
  File "rencode.pyx", line 244, in xpra.net.rencode._rencode.encode_list (xpra/net/rencode/rencode.c:2841)
  File "rencode.pyx", line 310, in xpra.net.rencode._rencode.encode (xpra/net/rencode/rencode.c:3879)
Exception: type <class 'xpra.net.protocol.LevelCompressed'> not handled

And this is fixed in r4644 by flattening the "clipboard-token-with-data" packets for OSX clients so that the network encoders don't encounter the compressed data. The other options would have been to:

Note: this changes the packet format, which will create incompatibilities between 0.11.x (trunk) pre and post r4644 with OSX clients, just avoid this mix.

As a semi-related note, trying to use the xpra gtk_view_keyboard source (and presumably the view_clipboard as well) inside the Python shell included in the Helpers directory produces an import error:

You're using the wrong python.

Either launch from the jhbuild shell, which has its own python installation. Or follow the comments in ticket:318#comment:4 (use Xpra.app/Contents/Helpers/Python)

r4647 adds a launch wrapper for the keyboard tool:

Xpra.app/Contents/Helpers/Keyboard_Tool

I am not adding one for the clipboard, because the OSX clipboard is so limited and different from the regular ones that the clipboard tool would be useless, and more confusing than anything.


Thu, 14 Nov 2013 20:31:00 GMT - alas:

As of 0.11-r4745 there is no "bounce" to the xpra icon when copying/pasting, there is no sign of a clipboard icon overlay, and there is no sign of client closing when copying relatively large blocks of data.

Also, the keyboard tool works quite nicely.


Fri, 15 Nov 2013 13:46:52 GMT - Antoine Martin: status changed; resolution set

Right, there won't be any dock bouncing anymore as we send the contents with the clipboard owner change packets, so there is never any pending transfers (at least going from server to client) on macosx.

I am confused and a bit tired so I hope I am not missing anything as I close this bug - at last! (feel free to re-open if anything is amiss)


Sat, 23 Jan 2021 04:50:17 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/275