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
Config:
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
xpra info clipboard
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2291