HTML5 client override local clipboard at client connection

[cdrcnm]

The html5 client override the client clipboard on the first click in the client window after connection.

How to reproduce:

1. Connect to xpra server with the html5 client
2. Copy string in xpra remote, for example "xpratest", and paste it on your computer. It's works as expected.
3. Copy string, for example "mylocalstring" from your computer and paste it in the remote client. It's work as expected.
4. Quit the html5 client (reload the page or even close the tab)
5. Reconnect with the html5 client and interact with it.
6. The local clipboard (the one on the computer) and remote (xpra server) clipboard will now be set to "xpratest". It's happen with a click, not even a text selection or ctrl-c.

Xpra client: html5 tags/2.5 (r22658) and also trunk r22658 on ArchLinux?? and Chromium 74

Xpra Server: 2.5.1-r22431 on Debian 9

Xpra config for clipboard:

desktop-fullscreen    (used)   = True   
clipboard                      = 'yes'
clipboard-direction            = 'both'
clipboard-filter-file           = ''
local-clipboard                = 'CLIPBOARD'
remote-clipboard               = 'CLIPBOARD'

Fullscreen desktop with openbox.

The clipboard debug log of the problem is attached.

[Antoine Martin]

That's the nature of the clipboard: the data is copied on request and when a client disappears, so does the data it held. (there are options to store clipboard contents after exit, but let's not go there)

[cdrcnm]

The problem is not that the content of the clipboard is not kept between reconnection.
After a reconnection, the local clipboard (the one on the computer) is overwritten by the one of the xpra server. And this event is done when there is a click. The clipboard synchronisation event shouldn't be launched only where there is a keyboard event like Ctrl-V or mouse selection event ?

[Antoine Martin]

The clipboard synchronisation event shouldn't be launched only where there is a keyboard event like Ctrl-V or mouse selection event ?

We send the initial clipboard data to prime the clipboard state.
We would need a way to send the clipboard token without actually sending the data with it.

[Antoine Martin]

No longer a problem, solved by #1844