Doesn't pass along mouse actions

[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]

Thanks, we'll look at this.

[suan]

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

[keithw]

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]

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]

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]

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]

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

Almost same for me.

I use mosh with everything else than WeeChatting. I am missing mouse with WeeChat, because it makes channel list script, buffers.pl, more useful in my opinion and mouse is nice to have with htop too, but it's easy to use even without mouse.

[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]

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

[danielb2]

👍

[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:
keithw#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 did you test my version? Can you explain how to reproduce your use
case if it's not working for you?
Thanks.
On Sep 30, 2013 12:12 PM, "phmarek" notifications@github.com wrote:

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.

—
Reply to this email directly or view it on GitHubhttps://github.com/keithw/mosh/issues/101#issuecomment-25349812
.

[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 keithw#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 👍 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]

It was merged.

[rekendahl]

Cool! I’m a couple of small versions behind on mosh on the Linux machine I’m using. Perhaps time to update and see if it works.

/Robert

On Jan 14, 2014, at 3:20 PM, Keith Winstein notifications@github.com wrote:

It was merged.

—
Reply to this email directly or view it on GitHub.

[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]

@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. 👍 Yes, you need to upgrade both the client & the server.

[pvaret]

Works fine. Thanks. :) I hope the mosh devteam will consider making a
release including this patch soon. It's a very useful feature to have
when using mosh in combination with tmux.

[keithw]

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 keithw#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]

👍 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]

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).

[chrisjohnson]

Just wanted to comment that miraculously, without ever touching either installation, the issue has gone away and mouse support works as of today. I just went to try libtermkey and it worked great, tested in vim, worked great, and as of yet I'm not even having any inconsistencies like @randywallace. I did nothing more than mosh my-host so perhaps a reboot on host or client cleared it up. Anyway thanks

[niieani]

@chrisjohnson thanks for the update. So it turns out it's like I said - the implementation is good, the problems were with the client/server installations...

[danielb2]

perl -E ' print "\e[?1005h\e[?1002h" ' no longer works with 1.2.5

[danielb2]

I made sure the mosh-server and client are both 1.2.5 but still no luck. Any idea what could be up with that?

[chrisjohnson]

The print trick should no longer be necessary. Make sure you build from source on both using the same commit. Then try manually specifying the full path to the binaries to be sure you call the built version

On Jul 29, 2015, at 11:09 PM, Daniel Bretoi notifications@github.com wrote:

perl -E ' print "\e[?1005h\e[?1002h" ' no longer works with 1.2.5

So this didn't get fixed but was made worse?

—
Reply to this email directly or view it on GitHub.

[danielb2]

Well, you made me double-check the versions which was good because for some reason the server did not get upgraded and was still stuck on 1.2.4. Thanks a bundle :)

[sparr]

I'm encountering this issue with 1.2.5

On Xubuntu, my mouse works fine in xterm+ssh and intermittently fails (scrolls the window buffer) with xterm+mosh.

On OSX, my mouse behaves as arrow keys in Terminal+ssh and Terminal+mosh. my mouse works as expected in iTerm2+ssh and always fails with iTerm2+mosh

[cgull]

Reports on mosh-1.2.5's mouse functionality have generally been positive, and I use mosh, iTerm2, xterm, and weechat regularly and it all works.
Are you sure you have mosh-1.2.5 installed on both clients and server? The mouse functionality is unlikely to work right if you have an older version of mosh installed at either end.
What application are you running on the server?

[jamorales-bsft]

on mac osx el capitan when I use the scroll wheel in a mosh terminal it goes through previous command as if I was pressing the up and down arrow keys. It does not actually scroll the terminal window at all.

[timotheecour]

@keithw , having the same issue:

ssh+tmux+mouse works
mosh+tmux+mouse doesn't work

mosh version=1.2.6 on both client and server
(ssh-ing from OSX to ubuntu, using iterm2)

[andersk]

@jamorales-bsft, @timotheecour: You are probably seeing #640 regarding iTerm2’s deep tmux integration (which, for reasons described there, only works over SSH), rather than this issue. You can get some level of mouse support in tmux without iTerm2’s deep integration by turning on tmux mouse mode (tmux < 2.1: set -g mode-mouse on, tmux ≥ 2.1: set -g mouse on).