xpra icon
Bug tracker and wiki

Opened 4 months ago

Last modified 6 weeks ago

#1461 new enhancement

html5 clipboard

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 2.0
Component: html5 Version: trunk
Keywords: Cc:


split from #1424

Code added in r15242.

Still TODO:

  • test with macosx, which may use a different value for the control key (apple key or whatever they decide to rename it to)
  • first few copy events don't always work (token is at the wrong end?)
  • would be nice to try to wait for the real clipboard contents (instead of the latest primary clipboard selection) so that applications that cook the clipboard data can be handled better (ie: browsers with google docs, etc) - but blocking the clipboard paste event handler may also block the network code that receives the response from the server?
  • maybe handle more mime types (may help with the issue above)

Attachments (2)

html5-clipboard-promise.patch (879 bytes) - added by Antoine Martin 4 months ago.
use a promise to delay handling the clipboard copy request - does not work
html5-clipboard-sleep.patch (561 bytes) - added by Antoine Martin 4 months ago.
busy wait for 150ms so the server can handle the clipboard copy event

Download all attachments as: .zip

Change History (13)

Changed 4 months ago by Antoine Martin

use a promise to delay handling the clipboard copy request - does not work

Changed 4 months ago by Antoine Martin

Attachment: html5-clipboard-sleep.patch added

busy wait for 150ms so the server can handle the clipboard copy event

comment:1 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

Synchronous Copy Events

In order to give enough time to the server so that it can process the copy request and gives us the correct clipboard value to use, I've tried using an async function (see attachment/ticket/1461/html5-clipboard-promise.patch) but the javascript clipboard API doesn't handle the promise as a value. (not surprising since this would bypass the clipboard access restrictions)

The busy wait approach (see attachment/ticket/1461/html5-clipboard-sleep.patch) does work, but:

  • it's a busy wait... ugly, burns CPU cycles for nothing, jquery also moans that it takes too long to execute
  • we would need to calculate a reasonable delay (hardcoded at 150ms in the patch), based on the RTT time (ping time) plus the time it takes for client applications to handle the event. (which can be anything.. it can even time out)
  • ideally we would exit the busy loop if we get a clipboard packet (would need a counter for "clipboard" clipboard inbound packets)
  • we still need the primary clipboard data as backup, in case the response doesn't arrive in time and also because we have no way of knowing when a "copy" button is clicked on... (and we don't want to delay all clicks just in case they happen to be on a clipboard button!)

So all in all, I'm not sure it is worth implementing. But maybe it helps with things like google docs? (not tested)

Mime Types


Doing a quick test with google chrome, copying some text on a page (all pages including google docs seem to give the same results) and viewing the list of targets that chrome provides for the clipboard using our view clipboard tool we see: STRING, UTF8_STRING, TEXT, text/plain and text/html. (TIMESTAMP and SAVE_TARGETS can be ignored)

So we should probably handle "text/html" server side and send more than one target - at the moment, we only send the first match (usually "UTF8_STRING").
That's going to be difficult: we have to request each target, those requests are asynchronous and the token packet is only meant to carry one value at a time..
On the plus side, this may help improve clipboard support for "greedy" platforms (win32 and osx).

Copying from the OS to the browser, we currently only request "text/plain", but we should be able to handle more than that. Even image formats if we wanted.
The difficulty in this direction is that with asynchronous clipboards (X11), we can't set multiple values so we would need to set multiple targets and keep a cache of the value for each target - then reply with the correct cached value if and when the server-side application requests it. Messy.

@afarr: how does that work for you? (note: as per ticket description, this has not been tested on osx and its special keycode for "control" may need tweeking)

Last edited 4 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 4 months ago by Antoine Martin

Minor improvements in r15273.

comment:3 Changed 3 months ago by Antoine Martin

Some reports of clipboard issues with:

  • different browsers
  • unicode characters copy + paste

See ticket:1487#comment:2

comment:4 Changed 3 months ago by Denis01

version - html5-2.0.1-2.r15507
1)Copy from windows into html client does not work (neither for EN no for other keyboards). Nothing is pasted.
2) Copy from html client into windows works well for EN and does not work for unicode (pastes but wrong symbols)

comment:5 Changed 3 months ago by Antoine Martin

Owner: changed from alas to Denis01

@Denis01 please specify:

  • full client OS version
  • exact chrome version
  • what you tried to copy and from where (plain text? from notepad?)
  • how you pasted: control-V? right click?
  • into what application?

The issue with Unicode characters on the clipboard should be fixed in r15512. (works for me)

comment:6 Changed 3 months ago by Denis01

CentOS Linux 7.3.1611
xpra X11 version 2.1-r15507 64-bit
Chrome 57.0.2987.133
Plain text. Notepad.

Getting worse. Now after several operations Copy-Paste (HTML->Notepad, Notepad->HTML) even in EN system stops to copy anything and keeps 2 splited clipboars (one as OS clipboard, another as HTML client clipboard)

Probably r15512 will fix. but still no update available.

comment:7 Changed 3 months ago by Antoine Martin

Owner: changed from Denis01 to alas

I suspect that the problem may be with the PRIMARY buffer selection which can generate hundreds of clipboard requests and cause the system to turn off the clipboard synchronization as a precaution. This would have shown as a warning in the log output, but @Denis01 did not include any output so it is impossible to tell.
If that's the case, we can deal with this problem as part of #1400.

@afarr: does this new clipboard code work well enough for you?

comment:8 Changed 3 months ago by Denis01

yes, too many requests to clipboard (details below).
And I noticed that it occurred when tried to copy multiple lines. For one, two, three..... words in one line it works normally.
is r15512 already published for test?

(gedit:24376): Gtk-WARNING **: Calling Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
2017-04-10 00:59:48,881 clipboard disabled: more than 20 clipboard requests per second!
2017-04-10 00:59:48,933 client 1: server set clipboard state to 0 reason was: more than 20 clipboard requests per second!
Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:9 Changed 2 months ago by Denis01

applied changes in r15512 (xpra X11 version 2.1-r15507 64-bit, Chrome). Didn't help.
Unicode copy from Notepad to HTML client - don't work
Copy from HTML client in Unicode symbols works but Notepad pastes non correct symbols (in wrong codification).
Other remarks:
even with En keyboard if there is a Space or Enter between words - the copying process is broken

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:10 Changed 6 weeks ago by Antoine Martin

@afarr: r15873 fixes the clipboard with macos clients, and we now also have the "swap command and control keys" option on the connect page.
Apple use the "meta" (aka "command") modifier instead of "control". This works reliably for me with chrome, not so well with Safari or Firefox. (someone who really cares about this evil combination of OS and browser could fix this I guess)
Unicode clipboard transfers also worked for me (in both directions with chrome), no idea what comment:9 is about.

PS: this will not be applied to the 2.0 branch that this ticket is for...

Last edited 6 weeks ago by Antoine Martin (previous) (diff)

comment:11 Changed 6 weeks ago by Denis01

HTML client, Chrome, Windows 7
For tests i always use "Cntr-C" for copy and "Cntrl-V" for paste
Libreoffice 5.2

everything seems fine except:
1) multiline copying.
From Notepad to XPRA works well but from XPRA to Notepad - not always (but oneline copying works well to both sides)
2) Copying in UNICODE.
Somethings one line text(unicode) with spaces doesn't work well from XPRA to Notepad.
3) if EN keyboard in tray "Cnt-C"+"Cntr-V" works but if RU keyboard in try - neither "Copy" no "Paste" works in XPRA

P.S. Comment:9. Everything works fine. Don't see now any issues. Resolved

Last edited 6 weeks ago by Denis01 (previous) (diff)
Note: See TracTickets for help on using tickets.