Sending Mouse inputs via ssh / Disabling context menu [Feature]

[nkay08]

Hello and thank you for your development of WindTerm. It is exactly what I was looking for: A FOSS cross-platform ssh/terminal/... client that is fast and does not eat a huge amount of resources.

I can comfortably work with WindTerm, however I found that it is impossible to send correct mouse inputs via ssh. E.g. I am logging in to my server via ssh on which I use tmux for multiplexing. I have set up tmux to accept mouse inputs for easier navigation.

• Currently WindTerm seems to send some inputs, for example right-click, but the popup of the WindTerm context menu interferes with it.
• Left-clicks seem to have no issue.
• Scrolling appears to have the effect of arrow up/down or page up/down. While my tmux is configured to have a buffer that I can scroll up to in other terminals

So my suggestions would be to to have an option to disable the WindTerm context menu, or only show it when pressing a hotkey.

Furthermore I found that copying lines when using tmux is impossible and seems to not copy the selection but something like: | ssh_tmu2:p4 3:[tmux]* 4:bash- |<host> | Thu 2021-08-05 10:09 , which is the status bar of tmux and the last line in the terminal.

[kingToolbox]

You are welcome, I'm glad you like WindTerm. Here are some answers to your questions.

• First, WindTerm already fully supports the VT mouse protocol and can send all mouse events to the server, including left-click, right-click, middle-click and mouse scrolling.
• Right-click and mouse scrolling are currently handled by WindTerm, and they are not sent to the server. Because this design is more convenient for most users.
• Right-click can already configure whether to pop up the right-click menu or paste text. The next version will support "send to remote".
• For mouse scrolling, I need specific analysis before I can decide to improve the design to meet your needs. And I will update the progress here.
• Copying lines may be a bug, I will test when I have time, if it is confirmed to be a bug, I will fix it.

The next version is expected to be released in late August.

[nkay08]

Thank you for your quick response and your clarification. Your description of the behaviour is exactly what I observed and assumed.

You are doing good work, and if I can assist you in any way, I'd be glad to help.

[kingToolbox]

Hi, WindTerm_2.2.0_Prerelease_2 has been released and Send right click events to the server feature has been implemented. You only need to check Right click event in the new Menubar - Session - Preferences - Settings dialog box to enable it, then all right-click events will be sent to the server, and the right-click menu will no longer be popped up.

Please download and check it, thank you.

BTW, copying lines in tmux will be investigated in later versions, I will update the progress here.

[kingToolbox]

@nkay08 Sorry, I have tried copy lines in tmux using ctrl+shift+c and Ctrl+B [, space, enter, Ctrl+], but I cannot reproduce the problem you mentioned. Would you please list the detailed steps? Thank you very much.

[nkay08]

Indeed, I cannot reproduce this error on other servers either. It seems this is an issue on that specific server only (e.g. some specific bash or tmux configuration). Copying does work in other terminals (mintty), though.

[kingToolbox]

I am happy to get your feedback. Can you remember how copying is done? I guess it should be done using tmux's built-in copy function, because if you use WindTerm's own copy function, for example, after selecting the text, press the ctrl+shift+c key to copy, I don't think there should be a problem.

[nkay08]

The confusing part is, that I was copying by ctrl+shift+c and not tmux's internal copy function. It works just as intended on other ssh servers that I tried, just not on this one.

[kingToolbox]

Do you mean that the problem of copying text still exists on that server until now?

[kingToolbox]

Although I did not declare, in fact WindTerm supports multiple carets and multiple texts copying. If you use the mouse to select text when pressing the ctrl key, you can actually select multiple blocks of text.

So I wonder if it is possible that the mouse clicked the last line when you pressed the Ctrl key, and then copying the text at this time will copy the last line as well. However, since it is a selection selected by using the Ctrl key, the caret of the selection is not visible.

You can open any session and try it out, then press the Ctrl key and click or drag several selections line by line in the multi-line text. At this time, the copied text by ctrl+shift+c is the multiple texts you selected.

One thing I can be sure of is that if you use the ctrl+shift+c key to copy text, it must have nothing to do with tmux and the server.

[nkay08]

I will check again and try to find out which specific behavior causes copying the wrong lines.

[kingToolbox]

Thank you very much. But please don't spend too much of your precious time. As long as it is a problem, it will reappear, and a problem that will never reappear is not a problem.

[nkay08]

I think I found the culprit: It is the setting set -g mouse on in my ~/.tmux.conf. There is probably some interaction where the tmux mouse mode enables selecting text, but only internally within tmux. WindTerm doesn't recognize this selection, because it was just sending the mouse inputs, which in turn leads to only selecting and copying the tmux status bar.

[kingToolbox]

Sorry for the late reply.

There are some control sequences that allow remote programs to set the local selection and clipboard, for example: ESC ] 52 ; Ⓢ ; Ⓑ ESC \ Set/Get Clipboard Contents ESC ] 1337 ;CopyToClipboard= Ⓢ ESC \ Copy to clipboard, iterm2 ESC ] 1337 ;Copy= Ⓑ ESC \ Copy to Pasteboard, iterm2

Tmux is likely to use these control sequences, but WindTerm does not support them for the time being, because I think it is risky to allow remote programs operate the local machine, but if you want, I can add this feature. When the remote programs tries to overwrite the local clipboard , I will pop up a box to ask for the user’s permission and let the user notice the existence of the operation.

Thank you very much for finding the source of this bug.