Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Doesn't pass along mouse actions #101

Closed
kergoth opened this Issue · 73 comments
@kergoth

When using an xterm-compatible terminal, one can use the mouse in some applications (e.g. tmux, vim). Mosh does not pass this along, but ssh does. This is a blocking issue for me, and I won't be switching from pure ssh to mosh until/if this is resolved.

@keithw
Owner

Thanks, we'll look at this.

@suan

Isn't this because mosh doesn't support X-forwarding?

@keithw
Owner

Nah, it's a textual protocol that xterm uses to convey mouse clicks to a terminal app. We just don't support it yet.

@kmcallister
Collaborator

Mosh advertises TERM=xterm so presumably we would support the Xterm mouse protocol on the server side.

According to /usr/share/doc/xterm/ctlseqs.txt.gz Xterm supports "six mutually exclusive modes". They're enabled with the "Set Mode (SM)" command (CSI?numberh) and disabled with "Clear Mode (CM)" (CSI?numberl). For example, "normal tracking mode" is enabled with CSI?1000h. Once a mouse mode is enabled, Xterm sends control codes back to the application on mouse click and/or movement. (Wheel scrolling is interpreted as clicks on one of two additional buttons.)

We would have to make the current mouse mode part of the synchronized terminal state, and interpret the mode-switching codes on the server. In the other direction, mouse reports can be part of the normal user input stream, and we might not even have to parse them client-side (but see below).

There is an orthogonal mode bit for "extended mouse mode" (CSI?1005h). In extended mode, the mouse reports encode position as UTF-8 characters. Without extended mode, "positions outside (160,94) result in byte pairs which can be interpreted as a single UTF-8 character; applications which do treat their input as UTF-8 will almost certainly be confused". By this I think they mean that the position is a single byte per axis, but that byte might have bit 7 set.

So regardless of what happens on the server, we want mosh-client to be in extended mouse mode. Unfortunately this was only recently added in Xterm, and isn't supported by my urxvt or gnome-terminal: these terminals send a single-byte position no matter what. And we'd still need to translate in the case where the remote application isn't expecting UTF-8 positions.

There is also a problem of synchronization between terminal state and the user input stream. If the remote application has already disabled mouse mode, but the client doesn't know yet, will the remote app get a stream of unexpected mouse reports? For this reason we might have to parse mouse events client-side and send them as a type of input event separate from keypresses.

So it's all a right mess, but definitely something users want.

@keithw
Owner

Thanks for looking into all that. I think for the very last issue, what you propose (parsing the mouse events client-side) is definitely the right thing.

The whole thing sounds pretty annoying though, especially if the clean approach only works in literal xterm.

@saurik

I have probably simply misinterpreted this explanation, but to verify: the idea is not to have the client always be in mouse mode, correct? It is normally the case that using "set mouse=a" and "set mouse=" in vim can switch your local terminal between using local and remote mouse events. If the local console were always using remote mouse events then it would become impossible to highlight/copy text locally in many terminals (such as iTerm2) and in others it would be possible but would require a modifier key.

@kmcallister
Collaborator

the idea is not to have the client always be in mouse mode, correct?

Correct. The mouse mode would be part of the state synchronized between the server (authoritative) and the client.

When I say "we want mosh-client to be in extended mouse mode", I'm referring to the independent bit that means "if we're in mouse mode, send positions as UTF-8 rather than single bytes". But I think this is not really usable because it's only supported by recent Xterm.

@HunterWare

I'll just chime in that this is blocking my switching to mosh. Otherwise it's basically perfect for my needs and generally great.

@Mikaela
@Synchro

@saurik you can use mouse events in iTerm2 - just press option to use local mouse control.

@ambientsound

I would also very much like to see this feature implemented. Using vim, I often use the mouse to scroll up and down. Through mosh, this is impossible. But if the feature was implemented, I would switch over completely :)

@Synchro

To be fair, I think screen presents quite a few problems for passing on mouse events too.

@andersk
Collaborator

The special case of scrolling up and down in applications like vim won’t actually need full mouse mode support. For that it’s enough to make sure that the client puts the real terminal in alternate screen mode (#2).

@grawity

@andersk, I believe that depends on the terminal used. For example, GNOME Terminal (and other vte-based terms) will translate scroll events to Up/Down arrow keys while in alt screen mode, but other terminals (Xterm, PuTTY) will not, and full mouse support remains necessary.

@FiXato

A workaround to this issue is to enable utf8 mouse mode before starting mosh.
For instance, running:
perl -E ' print "\e[?1005h\e[?1002h" '
before starting mosh allows me to use mouse support in my WeeChat client.

@theeternalsw0rd

If this can be done in perl, why not add a flag to the mosh wrapper script? Then worry about integrating if mosh gets to the point of being a single binary without the wrapper script.

@mdp

The workaround posted by @FiXato works in vim as well. This would be a nice addition to the wrapper.

@grawity

I noticed that VTE and PuTTY recently gained support for "xterm extended mouse tracking mode", DEC terminal modes 1006 (xterm) and 1015 (rxvt-unicode). Are those modes useful to mosh?

@chrisjohnson

The workaround by @FiXato works nicely for windows that make use of it, but then when I switch to my zsh window for instance, mouse clicks now spew out random characters. Any thoughts?

@hamiltont

Doubling @chrisjohnson comment: If I use workaround/mosh, then try to scroll up/down (using mac touchpad, dunno if it's important) in the iTerm2 window to see old history, I instead see tons of characters printed. In vim I get scrolling as expected

Also for remote vim: Seems the default mouse settings on my install worked for clicking windows, but not for resizing. I fixed this issue by explicitly using ":set ttymouse=xterm2" in my remote .vimrc . With that setting and @FiXato's workaround I have all mouse functionality when I'm inside vim

@mdp

I don't have a solution to fix this for vanilla terminal instances, but if you're using Tmux you can use the mouse in there as well, and without the usual ^B + [ rigamarole. Just add this to your tmux.conf

set -g mode-mouse on
@niieani

any news on this?
thanks!

@danielb2

@niieani try the trick of running perl -E ' print "\e[?1005h\e[?1002h" ' before starting the shell

@niieani

@danielb2 Yes, and it works, but it also turns on mouse events for everything, including shell which means typing in random characters after an accidental click (which otherwise switches for selection).

@niieani

I've implemented passing of the DEC mode for xterm mouse and xterm extended:
#461

Here's a ppa with the package for ubuntu:
ppa:nixin/mosh

@phmarek

Sending the escape sequence is sufficient to get window activation working in vim, but not for resizing them, ie. the borders cannot be dragged.

That would've been my favourite use case.

@niieani
@phmarek

No, I didn't test your version - I'm using straight debian packages. But perhaps file a bugreport so that it's included there?

I use mosh to some server, start vim, create a second window (eg. via "Ctrl-w s"), and normally the divider can be moved with the mouse.

(You might need ":set mouse=a" in vim, though.)

@niieani

It should work using my version. The Ubuntu package should also work on Debian, you can try it.
https://launchpad.net/~nixin/+archive/mosh

deb http://ppa.launchpad.net/nixin/mosh/ubuntu raring main
deb-src http://ppa.launchpad.net/nixin/mosh/ubuntu raring main

@przemekperon

Scrolling works with the version from PPA but clicks are not being recognized.

@niieani

What do you mean they aren't being recognized? In what case? please be specific.

@przemekperon

Clicking has no effect. Scrolling works but clicks don't. For example when using "mc".

I'm using gnome-terminal 3.6.2 on Linux Mint 15 (based on Debian).

Wrapper mentioned by blueyed doesn't work for me.

@niieani

Clicks in mc work for me, tested on iterm and putty. Are you sure it's not something with your configuration of gnome-terminal?

@emarcotte

Just want to point out that adding a \e[?1006h to the string at the end turns on the "extended" mouse support that makes it work better with wider terminals (at least for me).

@niieani

@emarcotte My version passes along everything that the origin sent. Extended support is nice and dandy, but it would cause incompatibility issues if forced every time. We should only try to pass along what's requested, nothing more, nothing less.

@HunterWare

@niieani Your version is working great for me, thank you. Do you have any idea when it might be accepted upstream?

@niieani

@HunterWare Well I don't, but this pull request #461 of mine has been there for some time now, and the patch seems to be solid without any problems reported, except for the experimental prediction mode, which itself has to be adjusted for mouse support.
I'm also waiting for it to be merged. :) Perhaps +1-ing it :+1: might help.

@rekendahl

I'd love to see #461 merged (assuming it works). I can click between different TMUX windows but I cannot resize TMUX windows by mouse in TMUX 1.9. I can do it over ssh

@keithw
Owner

It was merged.

@keithw keithw closed this
@rekendahl
@creack

The issue is still present. I don't manage to use the mouse with mosh client 1.2.4 osx and mosh server 1.2.4a ubuntu 64bits..
Using iTerm2 + tmux. TERM=screen-256color
It works just fine with ssh though. Any idea?

@andersk
Collaborator

@creack, this is fixed in Git (post-1.2.4a) by #461, as you can see in the comments above. There hasn’t been a release since then.

@pvaret

Sorry to bother -- @niieani, the package from your PPA doesn't install in Trusty due to a missing dependency. Would it be feasible to make a new release for Trusty? That would be awesome. :)

@niieani

@pvaret I'll definitely look into compiling a new package as soon as I have some free time, since I'm using Trusty myself now.

It's easy to do so yourself though, something like this should do the trick:

git clone https://github.com/keithw/mosh.git
export DEBFULLNAME="YOUR NAME"
export DEBEMAIL="YOUR-EMAIL@gmail.com"
apt-get build-dep mosh
apt-get source mosh
cd mosh-1.2.4
uupdate ../mosh
cd ../mosh-1.2.4
dpkg-buildpackage -us -uc -nc

Cheers

@pvaret

Ok, done. Phew! Thank you for the brief but to the point howto. :) uupdate was a little fiddly but in the end it worked.

I imagine I need to install the package on both the client and the server?

@niieani

No problem. :+1: Yes, you need to upgrade both the client & the server.

@pvaret
@keithw
Owner

We'd be grateful if somebody would take a look at #505 and fix the remaining mouse issues before we release.

@pluskid

Just realized all the frustrations related to mouse are caused by mosh... After switching back to ssh, everything works perfectly. Looking forward to see mosh fix the issues!

@niieani

@pluskid what's the issue for you?

@pluskid

@niieani I'm using iTerm2, and SSH to a remote host, where I open tmux, inside which I open a VIM. The mouse scrolling in VIM works fine if I'm using ssh, but it won't work when I'm using mosh. The same thing happens when I try to use mouse to scroll tmux history (after setting mode-mouse on in tmux config).

@niieani

@pluskid That'a really interesting, because I use mouse-mode on in tmux too and it works via PuTTY without any problems.
Does the mouse work in other apps? Like midnight commander? Are you using mosh compiled with mouse both on the server and the client?

@blueyed

@pluskid
Is your client and server(!) up to date?

Is your issue related to #505 ?

@pluskid

@niieani @blueyed I'm using mosh 1.2.4. I don't know we need a server side software in order for mosh to work? Here are my tests:

  • iTerm2 + SSH + VIM: scroll working
  • iTerm2 + SSH + tmux: scroll working
  • iTerm2 + SSH + emacs: scroll not working (I guess I need to configure Emacs in some way?)
  • iTerm2 + mosh + VIM: scroll not working
  • iTerm2 + mosh + tmux: scroll not working
  • iTerm2 + mosh + emacs: scroll not working

  • Terminal.app (Mac Native Terminal) + SSH + VIM: scroll not working

@niieani

@pluskid you can't use mosh 1.2.4 and expect the mouse to work. You need to compile the latest version yourself or use my ppa repository for ubuntu on both the client and the server.

@pluskid

@niieani Thanks! After updating both the client and server side mosh to the latest master, I successfully get the mouse working! Cheers!

@linjer

I came here for the same reason as @pluskid and I'm using the brew mosh 1.2.4 client and Fedora 1.2.4 server. I understand the feature was just added in a later build and I'm just wondering if you know when downstream sources will see the release @niieani ?

@niieani

@linjer If you use Ubuntu or Debian, get debs or use ppa from here:
https://launchpad.net/~nixin/+archive/ubuntu/mosh
Precompiled version with mouse.
As for your question, you really need to ask the maintainers of mosh.

@pmccarren

:+1: I'm blocking on this as well.

@chrisjohnson

I've upgraded my client and server (I built it from git on OS X -- client, and I installed the ppa package on Ubuntu -- server) and I still don't see any sort of mouse support. Is there a config flag I need to enable?

Here's my server:

~ ❯❯❯ mosh-server

MOSH CONNECT 60003 CGI2lrlYCw9rnI0Glb/VUA

mosh-server (mosh 1.2.4a)
...

And my client:

 chrisjohnson@chris-mbp ⮀ ~ ⮀ /usr/local/bin/mosh -v
mosh 1.2.4a
...

And when I run /usr/local/bin/mosh my-ubuntu-server, and try mouse support, I get nothing. Vim, vim inside screen, no clicks or scrolls are picked up by any applications on the other side. When I go back to ssh and do the same thing it works great. I tried starting a new screen session and tried running vim outside of screen, nothing seems to be registered. When I scroll, it scrolls my outer iTerm scrollback, not anything on the server.

I'm using iTerm + SSH/MOSH + ccreen + vim

What am I missing?

@mamiu

For me the same. Couldn't get it working!
Tried everything. Server and client are both running on the latest version (mosh 1.2.4a).

I'm also using iTerm2 + mosh + tmux/vim.

@andersk
Collaborator

Mouse support was added in Git after the release of 1.2.4a. It is not yet part of any released version. Until there’s another release, you’ll need to compile the server and client from Git.

@chrisjohnson

The above comment chain suggests that the ubuntu ppa should have these changes (my server), and as I mentioned I compiled from git on the client.

@niieani

@chrisjohnson You need to test with the exact same compilation on both the client and the server, because the ppa was compiled from my branch, which now is a bit outdated. There have been changes to the mouse support since, and they might have rendered it incompatible with my ppa. So either compile on both systems, or use the ppa on both of them.

@chrisjohnson

Ok, I removed the PPA version and compiled the server from git as well. The mosh-server and mosh-client outputs are still the same (1.2.4a). 100% positive I'm using the versions I just compiled. I'm using the master branch in both.

Same exact results, seemingly no mouse support whatsoever. Scrolling scrolls the iTerm buffer, nothing appears to be sent to the server. Clicks aren't picked up either (and I'm able to select words in vim with my mouse to be copied by iTerm -- something I can't do when mouse support is working). With and without screen.

@niieani

@chrisjohnson What's the output of echo $TERM for you? Did you try a different Terminal Emulator than iTerm?

@chrisjohnson

I have iTerm reporting xterm-256color (and $TERM mirrors that). I just tried on Terminal.app and I get the same result. Sadly I don't have a mouse to test on my local linux box, but I can see about trying PuTTY later? Though that doesn't really help since I'm obviously hoping to use my OS X terminal :P

@niieani

@chrisjohnson
You could also try testing with libTermKey's demo from:
http://www.leonerd.org.uk/code/libtermkey/
Compile and use: ./demo -m -p 1002

Other than that, I really don't know what might be causing this. Are you positive that you are executing the correct compilation of mosh? Or if the server is doing so? Perhaps you have a stale package or installation hanging around that gets executed instead. That might be the most likely thing, since mouse now seemed to be working for everybody. What does which mosh-server do for you on the server? Does it point to the place where you make installed your compiled mosh?

@mamiu

tl;dr: The main problem was the local installation. Now there's another problem with mouse on tmux.

Ok, I could solve the problem. The reason was, that I thought mosh on the client would automatically start the mosh-server which is given by which mosh-server on the server. But that's not true because .bashrc, .bash_profile (and all the other shell config files) aren't executed before starting the mosh-server, so the $PATH variable isn't set to the user specific paths and therefore the old mosh-server globally installed on the server is executed.
So I have to mosh into my server with

mosh --server="export LD_LIBRARY_PATH=/path/to/protobuf/installation/lib && /path/to/mosh/installation/mosh-server" -p 61234 user@host.com

after install mosh locally with this guide: https://gist.github.com/mamiu/24066ed58c158787c72f.

But now I have another problem: I can select text or panes only once, after that the mouse is disabled/locked. It behaves like the mouse outside tmux (or tmux with mouse mode disabled). This behavior doesn't occur when selecting windows at the bottom tmux bar (but after selecting text a second time I also can't switch windows with the mouse). Here's another person with the same problem: http://superuser.com/questions/882602/mouse-click-only-works-once-with-iterm2-tmux-mosh

Thanks a lot for all your help!

@chrisjohnson

Correct @niieani, I'm positively using the right installation. I blew away old installations first, which mosh-server verifies this. There's no other mosh-server on my filesystem. I'll try to give that demo a try over the next couple days. Thanks for the help

@dickinsonmg

I've just compiled on the client and server from the git commit c6cd99b version.

I'm also seeing the behavior that I'm only able to select panes once. I'm also using iTerm2 + mosh + tmux.

thanks.

@randywallace

Actually, I just recently went thru this step (getting my client and server on the latest code) last night, via https://github.com/randywallace/mosh-portfile, and ran into this as well. On my gateway server, I'm running also on c6cd99b. I thought it may have had something to do with the fact that I'm running nested tmux servers on several remote hosts (even tho everything works fine over plain-ole ssh), but seeing as how this is replicable by @dickinsonmg without my complicated setup, I am less inclined to think that is the issue.

I compiled and ran the demo over mosh to see what happened:

$ ./demo -m -p 1002
Mouse mode active
<MousePress(4)> at line=47, col=130
<MousePress(4)> at line=47, col=130
<MousePress(5)> at line=47, col=130
<MousePress(5)> at line=47, col=130
<MousePress(4)> at line=47, col=130
<MousePress(4)> at line=47, col=130
<MousePress(5)> at line=47, col=130
<MousePress(5)> at line=47, col=130
<MousePress(4)> at line=51, col=236
<C-c>
Mouse mode deactivated

It only works initially, or works for a little while, but it usually isn't long before I have to restart my mosh client->server connection to regain behavior. For example, if I start a new connection, open vim, set mouse=a, i can scroll all day long as long as I am in vim. Swap between insert/visual, visual select with the mouse, yank, paste, go back to visual mouse, no problem. If, though, I exit vim, then reopen vim, set mouse=a, and try again, it no longer works. Or sometimes it does.

Check this out:

~/git/libtermkey-0.17$ ./demo -m -p 1005
Mouse mode active
<MousePress(5)> at line=32, col=204
<MousePress(5)> at line=32, col=204
<MousePress(4)> at line=32, col=204
<MousePress(4)> at line=32, col=204
<MousePress(5)> at line=32, col=204
<MousePress(5)> at line=32, col=204
<MousePress(4)> at line=32, col=204
<MousePress(5)> at line=32, col=204
<C-c>
Mouse mode deactivated
~/git/libtermkey-0.17$ C`A`A`AaAaAaA`A`A`Aa

Note that the terminal after running the demo with mode 1005 throws strange characters on the terminal when I scroll the mouse. One time, even thought the terminal was showing that, I could still open vim, set mouse=a, and scrolling still works fine. Tmux scrolling was not working though.

BUT, in that case, I run the demo again afterward with 1002, I still get the libtermkey expected output. When I attempt to open vim afterward, though, and scroll, it won't work. Likewise, after running 1002, If I try 1005 again, that one won't work anymore either.

Also, things occasionally get really whacky and this happens (the character between MousePress(es) changed every time I ran the demo):

~/git/libtermkey-0.17$ ./demo -m -p 1005
Mouse mode active
<MousePress(5)> at line=145, col=162
P
<MousePress(4)> at line=145, col=162
P
<MousePress(5)> at line=145, col=162
P
<C-c>
Mouse mode deactivated

Not sure what to make of all this, but I hope this helps :) In the meantime, I'll just keep resetting my mosh connection when I need mouse support and it isn't working (woot, tmux).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.