Mosh clipboard issue #1090

jiaxincao · 2020-02-02T21:48:50Z

Line 114 in 0cc492d

if (f.get_clipboard() != frame.last_frame.get_clipboard()) {

It seems like that mosh is trying to create a clipboard caching to avoid OSC 52 clipboard delivery if the text is the same with the last time. However, this introduces a problem. Think of the following scenario, I'm using emacs in a remote server from my laptop via mosh, and trying to copy texts with OSC 52. I took the following steps.

My remote emacs sends a OSC 52 to deliver abc as the clipboard text. My local laptop clipboard and the mosh clipboard are both abc for now.
I copy something else (e.g., xyz) from another application on my local side, say, chrome. My local laptop clipboard is now xyz. The mosh clipboard is unchanged, which is still abc.
I went back to my remote emacs, and tries to send a OSC 52 to deliver abc to my local terminal again. However, this time, since the mosh clipboard still has the abc, it'll refuse to deliver OSC 52 with text abc to my terminal, which means that abc will not be copied to my local laptop clipboard.

I think the fundamental issue here is that mosh tries to do the clipboard caching, while there is no guarantee that the mosh cached clipboard is in sync with the local system clipboard. Anyone agree on this? Any workaround?

andersk · 2020-02-02T23:30:22Z

Yeah, this is a bug in #899 that I pointed out before (but thanks for opening an issue for it).

jiaxincao · 2020-02-03T00:54:24Z

@andersk , I don't think we are talking about the same issue. I see the issue reported even with your fix. Mosh refuses to transfer any OSC 52 code to the terminal if it was the same one with the last time.

andersk · 2020-02-03T01:22:47Z

We’re talking about the same issue: see item 2 of my comment that I linked. I didn’t say it was fixed, much less by me.

jiaxincao · 2020-02-03T01:45:29Z

Ah, you are right. So it seems like this is an issue that is still opening, correct?

Do you know why a clipboard cache was introduced in mosh? Why can we just sent the OSC 52 to the terminal only when the remote shell (or terminal applications) decides to do it?

Instead of using the contents of the clipboard to determine if the user has copied any text, use a sequence number that is updated whenever text is copied. Consider the following scenario (as described in mobile-shell#1090): 1. User copies text 'abc' on remote machine via mosh. 2. User copies text 'xyz' on local machine. 3. User copies text 'abc' on remote machine again. The local clipboard will still has 'xyz' because the most recent copy text 'abc' matches the last text copied via mosh, so it does not detect that the user copied new text and does not update the local clipboard. This patch updates detection of newly copied text via a sequence number. This number is an 8-bit unsigned integer that is updated every time new text is copied. This will roll over after 256 clipboard updates, but that is fine as we only care about it being different than the last value. Fixes mobile-shell#1090. Fixes mobile-shell#637.

The OSC 52 escape sequence supports specifying which X selection buffer place to the selection into. The protocol format is: \033]52;C;D\007 The C parameter determines the selection buffer. It consists of zero or more of the following characters: c: CLIPBOARD p: PRIMARY q: SECONDARY s: XTerm-selected (based on XTerm.vt100.selectToClipboard) 0-7: Numbered cut buffer The default if left blank is 's0', representing the configurable primary/clipboard selection and cut buffer 0. [1] D is the base64 encoded text to place in the selection buffer. This patch modifies the transferred clipboard data to include both the selection parameter and the base64 text. I.e. previously the transferred clipboard data only contained 'D', and now it contains 'C;D'. To test this functionality: 1. Open XTerm 2. Ctrl-Right Click and select 'Allow Window Ops' 3. Connect to a server w/ mosh 4. Run the following in the remote connection: $ printf "\033]52;c;$(echo test1234 | base64)\007" $ printf "\033]52;p;$(echo test2345 | base64)\007" $ printf "\033]52;q;$(echo test3456 | base64)\007" 6. Open another terminal on the local machine and run: $ xclip -o -selection clipboard test1234 $ xclip -o -selection primary test2345 $ xclip -o -selection secondary test3456 7. You can also try: $ printf "\033]52;;$(echo testdefault | base64)\007" (This should update either the clipboard or primary selection based on the Xterm settings) 8. To test the cut buffers you can use the same procedure, substituting the cut buffer number in C, and then use 'xcutsel' to transfer the data from the cut buffer to the PRIMARY selection, where it can then be viewed with 'xclip'. Note, I observed that XTerm does not currently (as of XTerm patch 358) support specifying more than one value in C. The specification does support it, and this appears to just be a simple bug in XTerm (a patch has been submitted to the maintainer to fix it). [1] https://github.com/ThomasDickey/xterm-snapshots/blob/master/ctlseqs.txt Fixes mobile-shell#967. Part 2 ====== Instead of using the contents of the clipboard to determine if the user has copied any text, use a sequence number that is updated whenever text is copied. Consider the following scenario (as described in mobile-shell#1090): 1. User copies text 'abc' on remote machine via mosh. 2. User copies text 'xyz' on local machine. 3. User copies text 'abc' on remote machine again. The local clipboard will still has 'xyz' because the most recent copy text 'abc' matches the last text copied via mosh, so it does not detect that the user copied new text and does not update the local clipboard. This patch updates detection of newly copied text via a sequence number. This number is an 8-bit unsigned integer that is updated every time new text is copied. This will roll over after 256 clipboard updates, but that is fine as we only care about it being different than the last value. Fixes mobile-shell#1090. Fixes mobile-shell#637.

Instead of using the contents of the clipboard to determine if the user has copied any text, use a sequence number that is updated whenever text is copied. Consider the following scenario (as described in mobile-shell#1090): 1. User copies text 'abc' on remote machine via mosh. 2. User copies text 'xyz' on local machine. 3. User copies text 'abc' on remote machine again. The local clipboard will still has 'xyz' because the most recent copy text 'abc' matches the last text copied via mosh, so it does not detect that the user copied new text and does not update the local clipboard. This patch updates detection of newly copied text via a sequence number. This number is an 8-bit unsigned integer that is updated every time new text is copied. This will roll over after 256 clipboard updates, but that is fine as we only care about it being different than the last value. Fixes mobile-shell#1090. Fixes mobile-shell#637.

mgulick linked a pull request Jul 23, 2020 that will close this issue

Support additional OSC 52 clipboard types #1104

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mosh clipboard issue #1090

Mosh clipboard issue #1090

jiaxincao commented Feb 2, 2020

andersk commented Feb 2, 2020

jiaxincao commented Feb 3, 2020 •

edited

Loading

andersk commented Feb 3, 2020

jiaxincao commented Feb 3, 2020

Mosh clipboard issue #1090

Mosh clipboard issue #1090

Comments

jiaxincao commented Feb 2, 2020

andersk commented Feb 2, 2020

jiaxincao commented Feb 3, 2020 • edited Loading

andersk commented Feb 3, 2020

jiaxincao commented Feb 3, 2020

jiaxincao commented Feb 3, 2020 •

edited

Loading