Xpra: Ticket #2291: HTML5 client send Primary clipboard even if disabled

When using the html5 client, the X11 PRIMARY clipboard is send to the clipboard, even when remote-clipboard = 'CLIPBOARD' is set on the server.

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


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

Fullscreen desktop with openbox.

Debug log:

2019-05-08 09:06:49,712 clipboard: PRIMARY owner_changed, enabled=True, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
2019-05-08 09:06:49,712 schedule_emit_token() elapsed=197811 (max=100)
2019-05-08 09:06:49,713 send clipboard token: PRIMARY
2019-05-08 09:06:49,713 client wants targets with the token, querying TARGETS
2019-05-08 09:06:49,713 get_contents(TARGETS, <function got_targets at 0x7fc106486b18>) selection=PRIMARY, enabled=True, can-send=True
2019-05-08 09:06:49,713 got_targets(<gtk.Clipboard object at 0x7fc11350cf00 (GtkClipboard at 0x55c191b75b30)>, ('TIMESTAMP', 'TARGETS', 'SAVE_TARGETS', 'MULTIPLE', 'STRING', 'UTF8_STRING', 'TEXT', 'text/plain'), (None,))
2019-05-08 09:06:49,713 got_targets for selection PRIMARY: ATOM, 32, ('TIMESTAMP', 'TARGETS', 'SAVE_TARGETS', 'MULTIPLE', 'STRING', 'UTF8_STRING', 'TEXT', 'text/plain')
2019-05-08 09:06:49,714 get_contents(STRING, <function got_contents at 0x7fc0fe24c320>) selection=PRIMARY, enabled=True, can-send=True
2019-05-08 09:06:49,714 remove_block: PRIMARY
2019-05-08 09:06:49,714 unpack <gtk.Clipboard object at 0x7fc11350cf00 (GtkClipboard at 0x55c191b75b30)>: <type 'gtk.SelectionData'>
2019-05-08 09:06:49,714 get_gtkselectiondata(<GtkSelectionData at 0x55c191c1b0c0>) type=<type 'gtk.SelectionData'>
2019-05-08 09:06:49,715 selectiondata: selection=0x1, target=0x1f, type=0x1f, format=0x8, length=0xe, data=0x55c1917d9b20
2019-05-08 09:06:49,715 unpack: <GtkSelectionData at 0x55c191c1b0c0>
2019-05-08 09:06:49,715 unpack(..) type=STRING, format=8, data=<type 'str'>:14
2019-05-08 09:06:49,715 got_contents for selection PRIMARY: STRING, 8, 'teststringcopy'
2019-05-08 09:06:49,715 _munge_raw_selection_to_wire('STRING', 'STRING', 8, 'teststringcopy')
2019-05-08 09:06:49,715 _do_munge_raw_selection_to_wire(STRING, STRING, 8, <type 'str'>:14)
2019-05-08 09:06:49,715 sending token with target data: ('STRING', 'STRING', 8, 'bytes', 'teststringcopy', True, False)
2019-05-08 09:06:49,718 client clipboard clipboard token: clipboard-token,PRIMARY,TIMESTAMP,TARGETS,SAVE_TARGETS,MULTIPLE,STRING,UTF8_STRING,TEXT,text/plain,STRING,STRING,8,bytes,teststringcopy,1,0
2019-05-08 09:06:49,863 client clipboard click event, with pending clipboard buffer= teststringcopy
2019-05-08 09:06:49,863 client clipboard copy event, clipboard buffer= teststringcopy

This doesn't happen with xpra_launcher 2.4.3

Wed, 08 May 2019 09:09:22 GMT - cdrcnm: attachment set

xpra info clipboard

Wed, 08 May 2019 10:31:48 GMT - Antoine Martin: status changed

I think that's working as intended.

The javascript access to the clipboard is very limited: when we get a request for the clipboard contents we have to supply it immediately, we cannot wait to send a message to the server and get the response. In most cases, using the PRIMARY clipboard allows us to have more up to date contents than what was in the CLIPBOARD clipboard last time we got it.

I'll re-test with the changes from #812 and see if that's still the case, or if we can do better.

Wed, 08 May 2019 13:46:45 GMT - cdrcnm:

ok, I understand the technical limitation. It's just confusing for the users to having the clipboard replaced, especially when selecting text for pasting over.

Mon, 03 Jun 2019 11:09:24 GMT - Antoine Martin: status changed; resolution set

This is fixed in r22839, but only if you use chrome which supports the new async API (#1844), other browsers will revert to the old behaviour.

The only other thing we could do would be to offer a toggle somewhere to disable this PRIMARY synchronization fallback. But I don't have time, so I'm closing this as 'fixed' because all the browsers will eventually support the new API.

Sat, 23 Jan 2021 05:47:17 GMT - migration script:

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