clipboard sharing stopped working from client to remote application

[ephestione]

I have searched the closed issues and found several hits, yet there seems to be nothing in the open ones. Briefly, clipboard sharing worked fine in firefox before, both ways, and I happily used it, until it didn't anymore. I cannot pinpoint it to a specific xpra update (using xpra.org source for apt in debian bullseye) because a few xpra updates were released between the previous time I needed to use the clipboard, and when I tried it again. What works, is copying inside the remote app, and pasting to the client side. But if I copy in client side and try to paste to remote app, the remote clipboard will not contain what I copied on the client side, it will either be empty, or contain whatever I had copied from the remote app.

It it's any help, both in chromium and in firefox I sometimes have to trigger the copy action multiple times inside the remote window, to actually have the clipboard contents also show in the client side.

[totaam]

Please include more details as per https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs

Clipboard synchronization keeps changing in browsers as they add and remove APIs, and / or make it more difficult to use existing ones. OTOH, using an SSL context (https) helps for some browsers. You could run both the xpra server (-d clipboard) and the html5 client ("clipboard debugging" in connect options) with debugging on, perhaps this will show where the data is getting wedged. My guess is that the browser is not providing the events - for whatever reason. It could also be related to #283 / #273

[ephestione]

I had bumped into #283 and #273 but thought they were at an advanced stage compared to mine because at least something was being copied :-) Here goes:

• debian bullseye on both sides, the server side has no graphic environment
• version installed v5.0.8-r0, html5 client 12.0 beta
• xpra start :100 --bind-tcp=0.0.0.0:<port>,auth=password:value=secret --html=on -d clipboard --clipboard=yes --clipboard-direction=both --start="<command>" is my syntax right now, client side I enabled clipboard sharing obviously, and now debug for clipboard

Checked trailing server.log with clipboard debugging on both sides, when copying from remote app a great deal of text is added to it, including the copied string, but since this works as intended to paste data from remote app to html5 client side, I suppose it's not interesting for you. When instead I copy a string on the client side, nothing is pasted to server.log. When, after trying to paste the string that was copied on client side, I pressed Ctrl-V inside the remote app, only this was shown:

client   1 clipboard polling: no data available

repeated 12 times. Subsequent attempts at pasting produced the same output, just in a smaller number of lines.

[ephestione]

BTW I tried reviewing the manpage, but I am too much of a newbie to understand what I need to do to run the html5 server through https :sweat:

[totaam]

--html=on --clipboard=yes --clipboard-direction=both

All of these are the default values and should not be needed.

but I am too much of a newbie to understand what I need to do to run the html5 server through https

"All" you need is a valid SSL certificate. The documentation has examples for generating one: https://github.com/Xpra-org/xpra/blob/master/docs/Network/SSL.md But... this will be a self-signed certificate, which may or may not be accepted properly by the browsers. Some do, some don't. It helps if you connect to it using localhost, you may be given the option to accept the cert, or not.

[ephestione]

Thank you, I just managed to connect on https, and same thing happens as detailed above, I can copy out, but it won't copy in

[totaam]

Then I guess that the next step is to look at the javascript console for clipboard messages after enabling "clipboard" debugging on the connect page. Hopefully it will show something useful. Be aware that the browser normally asks you if you want to give the page access to the clipboard, perhaps you've dismissed this dialog and access is now denied? (no idea where that setting is kept so you can make it ask again)

[ephestione]

Javascript console reports

Uncaught ReferenceError: text_html is not defined
    init_clipboard https://ip:port/js/Client.js:2050
9 Client.js:2050:13

usually preceded by

clipboard polling: no data available 3 Utilities.js:1:12047
clipboard pending= false buffer= <empty string>

So it doesn't look too helpful.

The remark about the page being able to access the clipboard made me ponder, but then I realized that I can copy from the remote app to client side, so xpra has write access to the clipboard, so why shouldn't it have read access, too? It might have happened (but not too sure about it) that I had switched from windows to linux when I started seeing this behaviour, I should boot into windows again (eugh) to see if it still works there.

[ephestione]

Just tried on firefox + windows, same symptoms. Since I was using clipboard normally while in windows, and no permissions dialogue appeared in the meantime, I can exclude that it's a clipboard access privilege issue.

[totaam]

Thank you for your patience. Obvious fix above. This code has been broken for a while and no-one noticed!

I will be making a bug fix release ASAP.

[ephestione]

Ahah, cool! I keep hitting the same kind of "dumb" errors myself those few times I mess with code ;-)

[totaam]

FYI: I have uploaded beta builds with this fix for most distributions: https://xpra.org/beta/

[ephestione]

I have installed the html5 component version 13, and now I see the following when I try and paste data into the remote app (it correctly shows "test" is the content of the clipboard), but nothing is actually pasted in the remote app:

2024-04-14 22:53:49,269 client   1 clipboard polling: no data available
2024-04-14 22:53:49,365 client   1 clipboard polling: no data available
2024-04-14 22:53:49,366 client   1 clipboard polling: no data available
2024-04-14 22:53:49,605 client   1 clipboard paste event, text= test
2024-04-14 22:53:49,606 client   1 clipboard sending clipboard token with data: 116,101,115,116 as text/html
2024-04-14 22:53:49,607 process clipboard token selection=CLIPBOARD, local clipboard name=CLIPBOARD, proxy=X11ClipboardProxy(CLIPBOARD)
2024-04-14 22:53:49,607 _filter_targets(text/html)=('text/html',)
2024-04-14 22:53:49,607 wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=4
2024-04-14 22:53:49,607 got token, selection=CLIPBOARD, targets=('text/html',), target data={'UTF8_STRING': ('UTF8_STRING', 8, b'test')}, claim=True, can-receive=True
2024-04-14 22:53:49,608 got_contents('TARGETS', 'ATOM', 32, b'\x93\x01\x00\x00\x00\x00\x00\x00') pending=
2024-04-14 22:53:49,608 got_contents('UTF8_STRING', 'UTF8_STRING', 8, b'test') pending=
2024-04-14 22:53:49,608 claim() we already own the 'CLIPBOARD' selection
2024-04-14 22:53:49,824 client   1 clipboard paste event, text= test
2024-04-14 22:53:49,825 client   1 clipboard sending clipboard token with data: 116,101,115,116 as text/html
2024-04-14 22:53:49,825 process clipboard token selection=CLIPBOARD, local clipboard name=CLIPBOARD, proxy=X11ClipboardProxy(CLIPBOARD)
2024-04-14 22:53:49,825 _filter_targets(text/html)=('text/html',)
2024-04-14 22:53:49,825 wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=4
2024-04-14 22:53:49,825 got token, selection=CLIPBOARD, targets=('text/html',), target data={'UTF8_STRING': ('UTF8_STRING', 8, b'test')}, claim=True, can-receive=True
2024-04-14 22:53:49,825 got_contents('TARGETS', 'ATOM', 32, b'\x93\x01\x00\x00\x00\x00\x00\x00') pending=
2024-04-14 22:53:49,826 got_contents('UTF8_STRING', 'UTF8_STRING', 8, b'test') pending=
2024-04-14 22:53:49,826 claim() we already own the 'CLIPBOARD' selection

Before, I could copy from the remote app and paste into itself, I just couldn't paste from client side into remote app, now nothing will work, but at least the debug message will show the clipboard contents.

[ephestione]

By the way, I can still copy in remote app and paste in client side.

[totaam]

I've done quite a bit of testing when I worked on #301 and could not reproduce any problems, so this will not be worked on.

[ephestione]

Well that's a bummer, as I just verified again, and with version 13 beta I cannot copy from host to the remote app, but can copy from remote app to host :shrug:

[totaam]

@ephestione have you tried hitting the new "copy" button in the top bar? Are you using an https context? Tried other browsers?

[ephestione]

I noticed the copy button reported in that other thread, I just don't know where it's featured :sweat_smile: I was already using the latest beta from the url you provided above, I uninstalled it and installed from apt but it got the normal version 12 which didn't show the button... I suppose it's not the end of the world, I can get to paste the kind of text I need by using the upload/download features, and creating dummy files in a samba share :stuck_out_tongue:

[totaam]

Run the latest code with:

rm -fr /usr/share/xpra/www/*
git clone https://github.com/Xpra-org/xpra-html5
rsync -rplv xpra-html5/html5/* /usr/share/xpra/www/

[ephestione]

I like being bleeding edge, I now have the clipboard button but unless I am not using it properly (clipboard of client is populated, I pressed the clipboard button on the interface, and then tried pasting into the field of remote app, but still nothing). Disabling the clipboardevents field in about:config still doesn't help. But I'm on firefox 120 and I should look into a way of having debian update it consistently, so maybe that's a reason, too.

[ephestione]

Updated to Firefox 126, no changes