Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
1.52k stars 144 forks source link

Clipboard synchronisation does not work properly #3884

Open s-kotte opened 1 year ago

s-kotte commented 1 year ago

Describe the bug

If a text is copied from the clipboard and pasted into the html5 client, it works the first time. If I copy a second text and paste it back into the html5 client, the text from the first time is still pasted.

Xpra Version

xpra server 4.4.4 with xpra-html5 client v7.0

Log: Copy "Test1" to clipboard

2023-06-06 14:08:35,701 process clipboard token selection=CLIPBOARD, local clipboard name=CLIPBOARD, proxy=X11ClipboardProxy(CLIPBOARD)
2023-06-06 14:08:35,701 _filter_targets(UTF8_STRING, text/plain)=('UTF8_STRING', 'text/plain')
2023-06-06 14:08:35,701 wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=5
2023-06-06 14:08:35,701 got token, selection=CLIPBOARD, targets=('UTF8_STRING', 'text/plain'), target data={'UTF8_STRING': ('UTF8_STRING', 8, 'Test1')}, claim=True, can-receive=True
2023-06-06 14:08:35,702 got_contents('TARGETS', 'ATOM', 32, b'\xef\x00\x00\x00\x00\x00\x00\x00\x98\x01\x00\x00\x00\x00\x00\x00') pending=
2023-06-06 14:08:35,702 got_contents('UTF8_STRING', 'UTF8_STRING', 8, Test1) pending=
2023-06-06 14:08:35,703 claim_selection: set selection owner returned 1, owner=0x80000d, owned=True
2023-06-06 14:08:35,703 claim_selection: sending message to root window
2023-06-06 14:08:35,703 claim_selection CLIPBOARD done
2023-06-06 14:08:35,704 do_xpra_xfixes_selection_notify_event(<X11:XFSelectionNotify {'send_event': '0', 'serial': '0x1c78', 'delivered_to': '0x80000d', 'window': '0x80000d', 'subtype': '0', 'owner': '0x80000d', 'selection': 'CLIPBOARD', 'timestamp': '103183927', 'selection_timestamp': '103183927'}>)
2023-06-06 14:08:35,704 do_selection_notify_event(<X11:XFSelectionNotify {'send_event': '0', 'serial': '0x1c78', 'delivered_to': '0x80000d', 'window': '0x80000d', 'subtype': '0', 'owner': '0x80000d', 'selection': 'CLIPBOARD', 'timestamp': '103183927', 'selection_timestamp': '103183927'}>) owned=True, was True (owner=0x80000d, xid=0x80000d), enabled=True, can-send=True
2023-06-06 14:08:35,705 do_xpra_selection_request(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1c79', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,705 do_selection_request_event(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1c79', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,706 clipboard request for CLIPBOARD from window ['xid=e00001', 'pid=151'], target=TARGETS, prop=SELECTION_DATA
2023-06-06 14:08:35,707 using existing TARGETS value as response: ('UTF8_STRING', 'text/plain')
2023-06-06 14:08:35,707 set_selection_response(<GdkX11.X11Window object at 0x7fe3a44fe400 (GdkX11Window at 0x219f920)>, TARGETS, SELECTION_DATA, ATOM, 32, b'\xef\x00\x00\x00\x00\x00\x00\x00\x98\x01\x00\x00\x00\x00\x00\x00', 0)
2023-06-06 14:08:35,709 do_xpra_selection_request(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1c98', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,709 do_selection_request_event(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1c98', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'TARGETS', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,710 clipboard request for CLIPBOARD from window ['xid=e00001', 'pid=151'], target=TARGETS, prop=SELECTION_DATA
2023-06-06 14:08:35,710 using existing TARGETS value as response: ('UTF8_STRING', 'text/plain')
2023-06-06 14:08:35,710 set_selection_response(<GdkX11.X11Window object at 0x7fe3ac09dc40 (GdkX11Window at 0x219f920)>, TARGETS, SELECTION_DATA, ATOM, 32, b'\xef\x00\x00\x00\x00\x00\x00\x00\x98\x01\x00\x00\x00\x00\x00\x00', 0)
2023-06-06 14:08:35,840 do_xpra_selection_request(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1cb4', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'UTF8_STRING', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,841 do_selection_request_event(<X11:SelectionRequest {'send_event': '0', 'serial': '0x1cb4', 'delivered_to': '0x80000d', 'window': '0x80000d', 'requestor': '0xe00001', 'selection': 'CLIPBOARD', 'target': 'UTF8_STRING', 'property': 'SELECTION_DATA', 'time': '0'}>)
2023-06-06 14:08:35,847 clipboard request for CLIPBOARD from window ['xid=e00001', 'pid=151'], target=UTF8_STRING, prop=SELECTION_DATA
2023-06-06 14:08:35,848 setting target data for 'UTF8_STRING': UTF8_STRING, 8, Test1 (<class 'str'>)
2023-06-06 14:08:35,849 set_selection_response(<GdkX11.X11Window object at 0x7fe3a44fe400 (GdkX11Window at 0x219f920)>, UTF8_STRING, SELECTION_DATA, UTF8_STRING, 8, Test1, 0)

Log: Copy "Test2" to clipboard

2023-06-06 14:08:48,650 process clipboard token selection=CLIPBOARD, local clipboard name=CLIPBOARD, proxy=X11ClipboardProxy(CLIPBOARD)
2023-06-06 14:08:48,651 _filter_targets(UTF8_STRING, text/plain)=('UTF8_STRING', 'text/plain')
2023-06-06 14:08:48,652 wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=5
2023-06-06 14:08:48,653 got token, selection=CLIPBOARD, targets=('UTF8_STRING', 'text/plain'), target data={'UTF8_STRING': ('UTF8_STRING', 8, 'Test2')}, claim=True, can-receive=True
2023-06-06 14:08:48,656 got_contents('TARGETS', 'ATOM', 32, b'\xef\x00\x00\x00\x00\x00\x00\x00\x98\x01\x00\x00\x00\x00\x00\x00') pending=
2023-06-06 14:08:48,657 got_contents('UTF8_STRING', 'UTF8_STRING', 8, Test2) pending=
2023-06-06 14:08:48,658 claim() we already own the 'CLIPBOARD' selection

I expect that when copying test2 for the second time, it will also be pasted and not test1.

totaam commented 1 year ago

Please provide more details: server OS, browser, command line, etc. What application do you use for copying to the clipboard?

The html5 client is meant to set the greedy property which should cause the server to send the updated data to the client.

s-kotte commented 1 year ago

The xpra server is running on a ubuntu:20.04 server with a wine 7 application shared via xpra. I have tested this on Windows with Firefox and Chrome, they behave the same. Whether I use ctrl + c or the context menu.

html5-Client settings:

floating_menu = yes
sound = no
video = no
blocked-hosts=xpra.org,www.xpra.org
encoding = png
keyboard_layout = de
clipboard = yes

xpra-server settings:

webcam=no
html=on
notifications=no
min-quality=98
exit-with-children=yes
env=XPRA_ACK_TOLERANCE=1000
pulseaudio=no
lock=yes
resize-display=4K

xpra command:

xpra start --start-child="wine ./program/LCS.exe" --bind-tcp=0.0.0.0:8085 --no-daemon
totaam commented 1 year ago

Does this also happen with a more easily installable application, say gedit?

s-kotte commented 1 year ago

It works fine with gedit.

It looks like it only works in wine if I copy and paste alternately between the systems. Meaning:

  1. html5: copy text
  2. windows: paste text
  3. windows: copy text
  4. html5: paste text

It does not work if I want to copy something from the same system twice in a row. Meaning:

  1. windows: copy text
  2. html5: paste text
  3. windows: copy text
  4. html5: paste text
totaam commented 1 year ago

Sounds like wine is not firing the clipboard change event. Are there any default wine applications that exhibit this problem? (I have no idea what LCS.exe is)

s-kotte commented 1 year ago

You can use the notepad.exe to test it.

totaam commented 1 year ago

OK. Will do.

totaam commented 1 year ago

The problem can be reproduced without the need for the html5 client, so I am moving the ticket to the xpra project.

totaam commented 1 year ago

Despite the fact that the wine code looks correct: winex11.drv/clipboard.c the clipboard handling is weird: it doesn't seem to claim the selection when you copy something to the clipboard in a wine application and it doesn't seem to monitor the selection for changes either.

Found some relevant links in Clipboard syncronization between wine and X11

I don't think I will have enough time to look into this further anytime soon as this is the type of ticket that takes ages to resolve. Sorry.

s-kotte commented 1 year ago

Anyway, thanks for the analysis. FYI, I was able to program a workaround. Clipboard synchronization works again when I manually trigger a clipboard change event in my Wine application.

totaam commented 3 months ago

@s-kotte I think 264e7c83d82aa1bc74306b618294d19b53d8b869 may be the fix for this bug. Can you try it? I can make new beta builds if needed. Are you still using Ubuntu 20.04?

s-kotte commented 2 months ago

@s-kotte I think 264e7c8 may be the fix for this bug. Can you try it? I can make new beta builds if needed. Are you still using Ubuntu 20.04?

Tested with the latest master version, unfortunately I can still reproduce the bug

totaam commented 1 month ago

@s-kotte can you provide a sample application that I can use to reproduce the issue? Can you still reproduce the problems with notepad.exe? (works fine for me)

s-kotte commented 3 weeks ago

Is the fix already in version 6.0.1? I can't use the master version at the moment, it's not working for me.

Tested in version 6.0.1 with notepad.exe and still reproducible

1: (Windows) Copy text 2: (Xpra client) Paste Step 2 does not work, no text is pasted

totaam commented 3 weeks ago

Your original description for this bug is:

If a text is copied from the clipboard and pasted into the html5 client, it works the first time. If I copy a second text and paste it back into the html5 client, the text from the first time is still pasted.

But in your latest comment, you seem to be copying from MS Windows to the xpra client? With a different result too: "no text is pasted". So this may well be a completely different issue.

The 264e7c83d82aa1bc74306b618294d19b53d8b869 fix (shipped in v6.0.1) was tested by: