Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clipboard needs an "explicit" text box to start working #3086

Closed
stdedos opened this issue Apr 9, 2021 · 18 comments
Closed

Clipboard needs an "explicit" text box to start working #3086

stdedos opened this issue Apr 9, 2021 · 18 comments
Labels
clipboard linux

Comments

@stdedos
Copy link
Collaborator

stdedos commented Apr 9, 2021 •
edited

Unless I've pasted in an explicit textbox, e.g.
Xpra_cmd_2021-04-09_10-29-52

The clipboard would refuse to paste e.g. in gnome-terminal or in LibreOffice Calc (Excel)

PS:

  • Are the buttons so ginormous for real?
  • Is the textbox so ginormous for real?
  • The textbox does not have word wrapping intentionally?

(PPS: This may be the 4.1.2 version)

PPPS: Look ma! I move the window from far far away! :-D
totaam added a commit that referenced this issue Apr 10, 2021
@totaam
#3086 use a more reasonable default size
82ed138
totaam added a commit that referenced this issue Apr 10, 2021
@totaam
#3086 add a multiline text entry area
189ae44
@totaam
Copy link
Collaborator

totaam commented Apr 10, 2021 •
edited

Unless I've pasted in an explicit textbox, e.g.

I don't understand this bit. Works for me, even with just xclip to retrieve the data. No textbox involved.

The clipboard would refuse to paste e.g. in gnome-terminal or in LibreOffice Calc (Excel)

Works-for-me(tm). It was not clear if those apps were supposed to be run from within the xpra session or from the Ubuntu desktop, so I've tried both. Both worked.
Though gnome-terminal takes forever to launch. (but that's a different problem)

Are the buttons so ginormous for real?

They're not for me.
ubuntu-focal-xpra-gui

Is the textbox so ginormous for real?

It was, now smaller: 82ed138

The textbox does not have word wrapping intentionally?

That was intentional. Now we have both with and without word wrapping: 189ae44

@stdedos
Copy link
Collaborator Author

stdedos commented Apr 12, 2021 •
edited

They're not for me.
ubuntu-focal-xpra-gui

You rendered it natively. I render via the win10 client.

I also can resize the window to the size you are showing - it's only the "default setting" that it loads so big.

@totaam
Copy link
Collaborator

totaam commented Apr 15, 2021

You rendered it natively. I render via the win10 client.

Doh! That will be why. A really silly bug too: 26586bf
(new beta posted)

Let's try to get back to the original bug then:

I don't understand this bit. Works for me, even with just xclip to retrieve the data. No textbox involved.

@stdedos
Copy link
Collaborator Author

stdedos commented Apr 15, 2021

I don't understand this bit. Works for me, even with just xclip to retrieve the data. No textbox involved.

I'll try to start with -d clipboard tomorrow, and see what I'll see.

@stdedos
Copy link
Collaborator Author

stdedos commented Apr 16, 2021 •
edited 

"Xpra-Python3-x86_64_4.2-r28905\xpra_cmd" attach ssh://user@ip/2 --ssh="plink -ssh -agent" -d notify,bandwidth -d clipboard --modal-windows=no --title="@title@ on @@/@server-display@" --headerbar=off --opengl=no --bandwidth-limit=6Mbps

XPRA_EXECUTABLE=Xpra-Python3-x86_64_4.2-r28905

2021-04-16 12:28:26,458 Xpra GTK3 client version 4.2 64-bit
2021-04-16 12:28:26,465  running on Microsoft Windows 10
2021-04-16 12:28:31,868 GStreamer version 1.18.4 for Python 3.8.9 64-bit
2021-04-16 12:28:32,688 created named pipe 'Xpra\2104'
2021-04-16 12:28:33,284 keyboard layout code 0x409
2021-04-16 12:28:33,301 identified as 'United States - English' : us
2021-04-16 12:28:33,777 make_clipboardmenuitem()
2021-04-16 12:28:34,452  keyboard settings: layout=us
2021-04-16 12:28:34,477  desktop size is 4160x1440 with 1 screen:
2021-04-16 12:28:34,482   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2021-04-16 12:28:34,483     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 132x131) workarea: 1600x860 at 0x534
2021-04-16 12:28:34,484     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400 at 1600x0
2021-04-16 12:28:38,794 DISCARD_TARGETS=re.compile('^NeXT'), re.compile('^com\\.apple\\.'), re.compile('^CorePasteboardFlavorType'), re.compile('^dyn\\.'), re.compile('^resource-transfer-format'), re.compile('^x-special/')
2021-04-16 12:28:38,800 DISCARD_EXTRA_TARGETS=re.compile('^SAVE_TARGETS$'), re.compile('^COMPOUND_TEXT'), re.compile('GTK_TEXT_BUFFER_CONTENTS')
2021-04-16 12:28:38,801 server clipboard: supported=True, direction=both
2021-04-16 12:28:38,803 client clipboard: supported=True, direction=both
2021-04-16 12:28:38,804 parse_clipboard_caps() clipboard enabled=True
2021-04-16 12:28:38,806 enabled remote logging
2021-04-16 12:28:38,808 Xpra GTK3 X11 server version 4.2-r28886 64-bit
2021-04-16 12:28:38,815  running on Linux Ubuntu 20.04 focal
2021-04-16 12:28:38,817 process_ui_capabilities() clipboard_enabled=True
...

2021-04-16 12:29:52,080 remove_block: CLIPBOARD
2021-04-16 12:32:31,884 process_clipboard_packet: clipboard-token, helper=ClipboardProtocolHelperCore
2021-04-16 12:32:31,888 process clipboard token selection=CLIPBOARD, local clipboard name=CLIPBOARD, proxy=Win32ClipboardProxy
2021-04-16 12:32:31,889 wire selection to raw, encoding=bytes, type=UTF8_STRING, format=8, len(data)=14
2021-04-16 12:32:31,890 got token, selection=CLIPBOARD, targets=(b'UTF8_STRING', b'TEXT', b'STRING', b'text/plain'), target data={'UTF8_STRING': ('UTF8_STRING', 8, b'172.16.253.193')}, claim=True, can-receive=True
2021-04-16 12:32:31,892 _filter_targets(UTF8_STRING, TEXT, STRING, text/plain)=('UTF8_STRING', 'TEXT', 'STRING', 'text/plain')
2021-04-16 12:32:31,893 _filter_targets(UTF8_STRING, TEXT, STRING, text/plain)=('UTF8_STRING', 'TEXT', 'STRING', 'text/plain')
2021-04-16 12:32:31,895 got_contents: tell OS we have UTF8_STRING, TEXT, STRING, text/plain
2021-04-16 12:32:31,896 we got a byte string: b'111.11.111.111'
2021-04-16 12:32:31,901 MultiByteToWideChar wlen=14
2021-04-16 12:32:31,902 GlobalAlloc buf=0x18ae0088
2021-04-16 12:32:31,904 with_clipboard_lock(1313290, <function Win32ClipboardProxy.set_clipboard_text.<locals>.set_clipboard_data at 0x0000000007161a60>, <function Win32ClipboardProxy.set_clipboard_text.<locals>.set_clipboard_error at 0x00000000071615e0>, 5, 10)
2021-04-16 12:32:31,905 OpenClipboard(0x140a0a)=1
2021-04-16 12:32:31,919 clipboard event: DESTROYCLIPBOARD, current owner: our window (hwnd=0x140a0a)
2021-04-16 12:32:31,921 EmptyClipboard()=1
2021-04-16 12:32:31,935 SetClipboardData(CF_UNICODETEXT, 14 chars)=414056584
2021-04-16 12:32:31,936 <function Win32ClipboardProxy.set_clipboard_text.<locals>.set_clipboard_data at 0x0000000007161a60>()=True
2021-04-16 12:32:31,938 CloseClipboard()=1
2021-04-16 12:32:31,940 clipboard event: CLIPBOARDUPDATE, current owner: our window (hwnd=0x140a0a)
2021-04-16 12:32:31,943 remove_block: CLIPBOARD
2021-04-16 12:36:55,630 clipboard event: DESTROYCLIPBOARD, current owner: our window (hwnd=0x140a0a)
2021-04-16 12:36:55,649 clipboard event: CLIPBOARDUPDATE, current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504)
2021-04-16 12:36:55,655 _send_clipboard_token_handler(Win32ClipboardProxy, ())
2021-04-16 12:36:55,658 send_clipboard_token_handler CLIPBOARD to CLIPBOARD
2021-04-16 12:36:55,659 clipboard_send: clipboard-token
2021-04-16 12:36:55,661 remove_block: CLIPBOARD
2021-04-16 12:36:55,703 process_clipboard_packet: clipboard-request, helper=ClipboardProtocolHelperCore
2021-04-16 12:36:55,708 process clipboard request, request_id=21, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
2021-04-16 12:36:55,710 get_contents('TARGETS', <function ClipboardProtocolHelperCore._process_clipboard_request.<locals>.got_contents at 0x0000000007161160>)
2021-04-16 12:36:55,711 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000071614c0>, 5, 10)
2021-04-16 12:36:55,715 OpenClipboard(0x140a0a)=[WinError 0] The operation completed successfully., current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504)
2021-04-16 12:36:55,721 process_clipboard_packet: clipboard-pending-requests, helper=ClipboardProtocolHelperCore
2021-04-16 12:36:55,723 clipboard_progress(None, 1)
2021-04-16 12:36:55,724 clipboard_notify(1) notification timer=None
2021-04-16 12:36:55,738 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000071614c0>, 4, 15)
2021-04-16 12:36:55,742 OpenClipboard(0x140a0a)=[WinError 0] The operation completed successfully., current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504)
2021-04-16 12:36:55,762 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000071614c0>, 3, 20)
2021-04-16 12:36:55,770 OpenClipboard(0x140a0a)=[WinError 0] The operation completed successfully., current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504)
2021-04-16 12:36:55,794 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000071614c0>, 2, 25)
2021-04-16 12:36:55,800 OpenClipboard(0x140a0a)=[WinError 0] The operation completed successfully., current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504)
2021-04-16 12:36:55,830 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000071614c0>, 1, 30)
2021-04-16 12:36:55,836 OpenClipboard(0x140a0a)=1
2021-04-16 12:36:55,838 get_clipboard formats()=HTML Format, CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT
2021-04-16 12:36:55,840 targets(HTML Format, CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT)=text/plain;charset=utf-8, UTF8_STRING, CF_UNICODETEXT, TEXT, STRING, text/plain
2021-04-16 12:36:55,842 proxy_got_contents(21, CLIPBOARD, TARGETS, ATOM, 32, <class 'list'>:6) data=0x5b27746578742f706c61696e3b636861727365743d7574662d38272c2027555446385f535452494e47272c202743465f554e49434f444554455854272c202754455854272c2027535452494e47272c2027746578742f706c61696e275d..
2021-04-16 12:36:55,848 _filter_targets(text/plain;charset=utf-8, UTF8_STRING, CF_UNICODETEXT, TEXT, STRING, text/plain)=('text/plain;charset=utf-8', 'UTF8_STRING', 'CF_UNICODETEXT', 'TEXT', 'STRING', 'text/plain')
2021-04-16 12:36:55,850 clipboard raw -> wire: ('ATOM', 32, ['text/plain;charset=utf-8', 'UTF8_STRING', 'CF_UNICODETEXT', 'TEXT', 'STRING', 'text/plain']) -> ('atoms', ('text/plain;charset=utf-8', 'UTF8_STR .. F_UNICODETEXT', 'TEXT', 'STRING', 'text/plain'))
2021-04-16 12:36:55,853 clipboard_send: clipboard-contents
2021-04-16 12:36:55,854 <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x0000000007161820>()=True
2021-04-16 12:36:55,856 CloseClipboard()=1
2021-04-16 12:36:56,042 process_clipboard_packet: clipboard-pending-requests, helper=ClipboardProtocolHelperCore
2021-04-16 12:36:56,046 clipboard_progress(None, 0)
2021-04-16 12:36:56,048 clipboard_notify(0) notification timer=None
2021-04-16 12:37:01,954 process_clipboard_packet: clipboard-request, helper=ClipboardProtocolHelperCore
2021-04-16 12:37:01,958 process clipboard request, request_id=22, selection=CLIPBOARD, local name=CLIPBOARD, target=text/plain;charset=utf-8
2021-04-16 12:37:01,960 get_contents('text/plain;charset=utf-8', <function ClipboardProtocolHelperCore._process_clipboard_request.<locals>.got_contents at 0x0000000007161700>)
2021-04-16 12:37:01,964 with_clipboard_lock(1313290, <function Win32ClipboardProxy.get_clipboard_text.<locals>.get_text at 0x000000000715e1f0>, <function Win32ClipboardProxy.get_contents.<locals>.errback at 0x0000000007161dc0>, 5, 10)
2021-04-16 12:37:01,965 OpenClipboard(0x140a0a)=1
2021-04-16 12:37:01,966 get_clipboard formats()=HTML Format, CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT
2021-04-16 12:37:01,971 supported formats: CF_UNICODETEXT, CF_TEXT, CF_OEMTEXT (prefer utf8: True)
2021-04-16 12:37:02,017 GetClipboardData(CF_UNICODETEXT)=0x187a2b10
2021-04-16 12:37:02,020 got data handle lock 0x187a2b10 for format 'CF_UNICODETEXT'
2021-04-16 12:37:02,022 got 26 bytes of UNICODE data: b'iiiiiiiiiiiiiiiiiiiiiiiiiiiii'
2021-04-16 12:37:02,023 got_text(b'iiiiiiiiiiiiiiiiiiiiiiiiiiiii')
2021-04-16 12:37:02,024 proxy_got_contents(22, CLIPBOARD, text/plain;charset=utf-8, text/plain;charset=utf-8, 8, <class 'bytes'>:26) data=0x6969696969696969696969696969696969696969696969696969..
2021-04-16 12:37:02,025 _munge_raw_selection_to_wire('text/plain;charset=utf-8', 'text/plain;charset=utf-8', 8, 'iiiiiiiiiiiiiiiiiiiiiiiiiiiii')
2021-04-16 12:37:02,027 _do_munge_raw_selection_to_wire(text/plain;charset=utf-8, text/plain;charset=utf-8, 8, <class 'bytes'>:26)
2021-04-16 12:37:02,028 clipboard raw -> wire: ('text/plain;charset=utf-8', 8, b'iiiiiiiiiiiiiiiiiiiiiiiiiiiii') -> (b'bytes', b'iiiiiiiiiiiiiiiiiiiiiiiiiiiii')
2021-04-16 12:37:02,033 clipboard_send: clipboard-contents
2021-04-16 12:37:02,035 <function Win32ClipboardProxy.get_clipboard_text.<locals>.get_text at 0x000000000715e1f0>()=True
2021-04-16 12:37:02,037 CloseClipboard()=1
2021-04-16 12:37:02,038 process_clipboard_packet: clipboard-pending-requests, helper=ClipboardProtocolHelperCore
2021-04-16 12:37:02,040 clipboard_progress(None, 1)
2021-04-16 12:37:02,045 clipboard_notify(1) notification timer=None
2021-04-16 12:37:02,178 process_clipboard_packet: clipboard-pending-requests, helper=ClipboardProtocolHelperCore
2021-04-16 12:37:02,182 clipboard_progress(None, 0)
2021-04-16 12:37:02,183 clipboard_notify(0) notification timer=None

Notice the 5-second delay
(it didn't used to be like that - but I don't know if I waited 5 seconds or not)

@totaam
Copy link
Collaborator

totaam commented Apr 16, 2021

There's nothing unusual in that log:

  • vivaldi.exe updates the clipboard contents: clipboard event: CLIPBOARDUPDATE, current owner: 'vivaldi.exe' with pid 5476 (hwnd=0x30504) and we send the token
  • the server then immediately requests the targets: process clipboard request, request_id=21, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS - only the server log can tell us which application is being this greedy
  • then 5 seconds later, we get a request for text/plain;charset=utf-8: process clipboard request, request_id=22, selection=CLIPBOARD, local name=CLIPBOARD, target=text/plain;charset=utf-8

My guess is that the application which is requesting the clipboard data is being facetious and maybe requesting an invalid target
(we have a ticket somewhere like that), and only requesting a valid one after timing out its invalid request.

Only the server's -d clipboard log can tell us what's really going on here.

@stdedos
Copy link
Collaborator Author

stdedos commented Apr 16, 2021

gnome-terminal is the requestee.

I knew it was gonna come to that 😛
I'll do it next week. At least replication is accurate; the first request of each client misbehaves, unless something

@stdedos
Copy link
Collaborator Author

stdedos commented Apr 19, 2021

Sadly, I couldn't do it today 😕
redact-display-_2-20210415-144236.log

@stdedos
Copy link
Collaborator Author

stdedos commented May 1, 2021

I think I must have replicated it
redact-display-_2-20210415-144236.log

and I am pretty sure you'll see it here:
clipboard-redact-display-_2-20210415-144236.log

@totaam
Copy link
Collaborator

totaam commented May 3, 2021

I only found the bug right at the end. So I'll keep the log summary I had already written for reference.

From the first log, the clipboard bits start near 2021-04-19 10:09:17:

client   4 @41.537 clipboard event: CLIPBOARDUPDATE, current owner: 'C:\Users\user.win\AppData\Local\Programs\Microsoft VS Code\Code.exe' with pid 7488 (hwnd=0x240736)
clipboard request for CLIPBOARD from window 0x600002: 'Terminal', target=TARGETS, prop=GDK_SELECTION
clipboard request for CLIPBOARD from window 0x10006f5: 'LibreOffice 7.1', target=TARGETS, prop=GDK_SELECTION
client   4 @41.590 process clipboard request, request_id=39, selection=CLIPBOARD, local name=CLIPBOARD, target=TARGETS
client   4 @41.661 with_clipboard_lock(21563896, <function Win32ClipboardProxy.get_contents.<locals>.got_clipboard_lock at 0x00000000183d6040>, <function Win32ClipboardProxy.get_contents.<locals>.lockerror at 0x00000000183d
68b0>, 2, 25)
client   4 @41.665 get_clipboard formats()=HTML Format, CF_UNICODETEXT, Chromium Web Custom MIME Data Format, 16, CF_TEXT, CF_OEMTEXT
client   4 @41.666 targets(HTML Format, CF_UNICODETEXT, Chromium Web Custom MIME Data Format, 16, CF_TEXT, CF_OEMTEXT)=text/plain;charset=utf-8, UTF8_STRING, CF_UNICODETEXT, TEXT, STRING, text/plain
setting response b'q\x01\x00\x00\x00\x00\x00\x00\xf2\x00\x00\x00\ .. 00\x00\x00\x00\x00t\x01\x00\x00\x00\x00\x00\x00' as 'TARGETS' on property 'GDK_SELECTION' of window 'Terminal' as ATOM
setting response b'q\x01\x00\x00\x00\x00\x00\x00\xf2\x00\x00\x00\ .. 00\x00\x00\x00\x00t\x01\x00\x00\x00\x00\x00\x00' as 'TARGETS' on property 'GDK_SELECTION' of window 'LibreOffice 7.1' as ATOM

Which seems perfectly normal, we even reply to two applications (Terminal and LibreOffice) requesting the same list of clipboard TARGETS with a single roundtrip message.

Shortly after that:

clipboard request for CLIPBOARD from window 0x600002: 'Terminal', target=text/plain;charset=utf-8, prop=GDK_SELECTION
client   4 @44.425 process clipboard request, request_id=40, selection=CLIPBOARD, local name=CLIPBOARD, target=text/plain;charset=utf-8
client   4 @44.470 got 30 bytes of UNICODE data: b'Xpra-Python3-x86_64_4.2-r28905'
setting response b'Xpra-Python3-x86_64_4.2-r28905' as 'text/plain;charset=utf-8' on property 'GDK_SELECTION' of window 'Terminal' as text/plain;charset=utf-8

Terminal asked for text/plain;charset=utf-8 and we correctly retrieved it from the UNICODE clipboard value on the MS Windows side.

From the second log, near 2021-04-23 10:19:05:

requesting local XConvertSelection from 'Terminal' as 'TARGETS' into 'PRIMARY-TARGETS'
got_targets: ('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'UTF8_STRING', 'COMPOUND_TEXT', 'TEXT', 'STRING', 'text/plain;charset=utf-8', 'text/plain')
requesting local XConvertSelection from 'Terminal' as 'UTF8_STRING' into 'PRIMARY-UTF8_STRING'
got_text_target(UTF8_STRING, 8, b'18')
client   9 @41.817 ignoring token for clipboard 'PRIMARY' (no proxy)

So the minor problem here is that the server is sending clipboard packets for PRIMARY, but the MS Windows clients only syncs with CLIPBOARD. Just wasted bandwidth.
FYI: I want to try to make MS Windows clients sync with both PRIMARY and CLIPBOARD at some point.
Then immediately after, the selection is copied to the "real" clipboard (I assumed you did a "copy"):

requesting local XConvertSelection from 'Terminal' as 'TARGETS' into 'CLIPBOARD-TARGETS'
got_targets: ('TIMESTAMP', 'TARGETS', 'MULTIPLE', 'SAVE_TARGETS', 'UTF8_STRING', 'COMPOUND_TEXT', 'TEXT', 'STRING', 'text/plain;charset=utf-8', 'text/plain')
requesting local XConvertSelection from 'Terminal' as 'UTF8_STRING' into 'CLIPBOARD-UTF8_STRING'
got_text_target(UTF8_STRING, 8, b'18')
client   9 @42.876 got_contents: tell OS we have UTF8_STRING, TEXT, STRING, text/plain
client   9 @42.879 we got a byte string: b'18'
client   9 @42.915 SetClipboardData(CF_UNICODETEXT, 2 chars)=464060536
client   9 @42.921 clipboard event: CLIPBOARDUPDATE, current owner: our window (hwnd=0x5c08d8)

Again, everything is as it should be.

Finally. The bug.

Near 10:19:11 to 10:19:14:

client   9 @48.002 clipboard event: CLIPBOARDUPDATE, current owner: 'C:\Users\user.win\AppData\Local\Vivaldi\Application\vivaldi.exe' with pid 5476 (hwnd=0x30504)
claim_selection: done, owned=True
clipboard request for CLIPBOARD from window 0x10006f5: 'LibreOffice 7.1', target=TARGETS, prop=GDK_SELECTION
clipboard request for CLIPBOARD from window 0x600002: 'Terminal', target=TARGETS, prop=GDK_SELECTION
client   9 @48.148 get_clipboard formats()=CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT
client   9 @48.149 targets(CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT)=text/plain;charset=utf-8, UTF8_STRING, CF_UNICODETEXT, TEXT, STRING, text/plain
clipboard request for CLIPBOARD from window 0x600002: 'Terminal', target=text/plain;charset=utf-8, prop=GDK_SELECTION
send_clipboard_request CLIPBOARD to CLIPBOARD, id=294
Warning: remote clipboard request timed out
 request id 294, selection=CLIPBOARD, target=text/plain;charset=utf-8

Then a few seconds later (too late):

clipboard request for CLIPBOARD from window 0x735aa3: 'Terminal', target=text/plain;charset=utf-8, prop=GDK_SELECTION
already waiting for 'text/plain;charset=utf-8' remote request: [(<GdkX11.X11Window object at 0x7fdd8bcb14c0 (GdkX11Window at 0x7eec720)>, 'text/plain;charset=utf-8', 'GDK_SELECTION', 1275631907)]
client   9 @51.707 process clipboard request, request_id=294, selection=CLIPBOARD, local name=CLIPBOARD, target=text/plain;charset=utf-8
get_clipboard formats()=CF_UNICODETEXT, 16, CF_TEXT, CF_OEMTEXT
got 172 bytes of UNICODE data: b'http://....txt'
Warning: request id 294 not found
 already timed out or duplicate reply

But the next request (295) does make it through in time:

setting response b'http://....txt' as 'UTF8_STRING' on property 'GDK_SELECTION' of window 'Terminal' as UTF8_STRING

So, what's happening here is that it takes too long for the clipboard request (it takes over 1.5 seconds) and we hit the timeout.
You can change this behaviour using: XPRA_CLIPBOARD_REMOTE_TIMEOUT=5000 to allow up to 5 seconds before we timeout a clipboard request. Whether the application you're using will timeout itself before that or not is not known.

Ideally, we should figure out why your connection has such high latency at times. As it makes everything difficult.

@stdedos
Copy link
Collaborator Author

stdedos commented May 3, 2021

Ideally, we should figure out why your connection has such high latency at times. As it makes everything difficult.

I would like to have a simple, external server/client model continuously monitoring those data, but I don't know what it should be (or how should I write such code!).

  • Are we just going to plot latency/jitter?
  • Of small or big data?
  • TCP, UDP, or both?

My "problem" with this is that I believe I can replicate it accurately at almost all times (>= 80%~90%), lacking any specific formalism proving otherwise. However, your log data point always to latency; which is not unreasonable, but "fail to satisfy" my observations (at least in full) given that I feel that there are workarounds.

My setup is the "well known" one: ADSL line encapsulated in an IPSec VPN.

@stdedos
Copy link
Collaborator Author

stdedos commented May 4, 2021

So, what's happening here is that it takes too long for the clipboard request (it takes over 1.5 seconds) and we hit the timeout.
You can change this behaviour using: XPRA_CLIPBOARD_REMOTE_TIMEOUT=5000 to allow up to 5 seconds before we timeout a clipboard request. Whether the application you're using will timeout itself before that or not is not known.

Is this server-side, or client-side? If it's server-side, because of #3088 I cannot apply it via environment variables.
Speaking of changing server settings on-the-fly ... would you consider an xpra control :2 env XPRA_CLIPBOARD_REMOTE_TIMEOUT 5000-like system? Something like sysctl https://www.cyberciti.biz/faq/howto-set-sysctl-variables/
Since you have modular code, can you reload modules? (or delay expansion/fetching at the very last second of calling?)

@stdedos
Copy link
Collaborator Author

stdedos commented May 4, 2021

Also

xpra/xpra/clipboard/clipboard_timeout_helper.py

Line 18 in 8d42d28

assert 0<REMOTE_TIMEOUT<5000

pls 😛

@stdedos
Copy link
Collaborator Author

stdedos commented May 4, 2021

Applying the above suggestion on the client, and starting with the remote end first, clipboard works as expected.

totaam added a commit that referenced this issue May 4, 2021
@totaam
#3086 longer default remote timeout, clamp the values rather than bai…
04d234a 
…ling out with an exception
@totaam
Copy link
Collaborator

totaam commented May 4, 2021

Is this server-side, or client-side?

Both. Clipboard synchronizes both ways.

As per the commit just above increasing the default timeout value, it should be much more difficult to trigger now.
Can we finally close this ticket?

Can you just explain what you meant by "needs an explicit text box to start working"?
I never really understood that part.

would you consider an xpra control :2 env XPRA_CLIPBOARD_REMOTE_TIMEOUT 5000-like system?
...
Since you have modular code, can you reload modules?

No. That would be too messy.

(or delay expansion/fetching at the very last second of calling?)

That could be done, but the code would be a little bit harder to read.
And it would take a lot of time to change all the environment variable lookups:

$ grep -r envint ./xpra/ | egrep -v ".c:|.html:"  | wc -l
334
$ grep -r envbool ./xpra/ | egrep -v ".c:|.html:"  | wc -l
516
$ grep -r os.environ.get ./xpra/ | egrep -v ".c:|.html:"  | wc -l
314

@stdedos
Copy link
Collaborator Author

stdedos commented May 4, 2021 •
edited

Can we finally close this ticket?

Okay, I guess, if it is bothering so much 😂

Can you just explain what you meant by "needs an explicit text box to start working"?
I never really understood that part.

gnome-terminal: Does not work.
libre-office-calc: Highlighting a cell: Does not work
libre-office-calc: Editing a cell: Works
sublime-merge: "Ctrl+Shift+P" (type command): Works
pycharm: Editing a file: Does not work
pycharm: "Ctrl+Shift+P" (type command): Works
sublime-text: Works

¯\_(ツ)_/¯

@stdedos stdedos closed this as completed May 4, 2021
totaam added a commit that referenced this issue May 4, 2021
@totaam
#3086 longer default remote timeout, clamp the values rather than bai…
0116212 
…ling out with an exception
@totaam
Copy link
Collaborator

totaam commented May 4, 2021 •
edited

gnome-terminal: Does not work.
libre-office-calc: Highlighting a cell: Does not work
...
pycharm: Editing a file: Does not work

What doesn't work? Cutting? pasting? Works-for-me(tm) in both directions with gnome-terminal. (ignoring #3109)
What am I doing wrong?

Reminder: you have to tell gnome-terminal to copy, selecting text only goes to the PRIMARY clipboard which is not available on MS Windows. (yet)

@stdedos
Copy link
Collaborator Author

stdedos commented May 5, 2021

What doesn't work? Cutting? pasting? Works-for-me(tm) in both directions with gnome-terminal. (ignoring #3109)

First time pasting, sending from client to server.
It seems though the 5s-delay is more than enough to fix this (near-instantaneously, if I may add; which makes me wonder wtf is that 5s delay if the paste happens well under 1s 😂).

So YEEEEEEH FIXED 😀

Reminder: you have to tell gnome-terminal to copy, selecting text only goes to the PRIMARY clipboard which is not available on MS Windows. (yet)

Yeah, I know that, I am talking specifically about Ctrl+Shift+V.
I actually like that the PRIMARY clipboard is separate from the Windows clipboard (since Windows has one clipboard), so I hope fixing that won't inhibit current behavior.

@stdedos stdedos mentioned this issue Jun 21, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clipboard linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stdedos @totaam