Spurious characters when using tmux 'mouse-select-pane'
By clint.hep... on April 22, 2011 12:55 (imported from Google Code)
What steps will reproduce the problem?
- In tmux, set mouse-select-pane on
- Clicking in a pane sometimes types spurious characters.
- Turning mouse-select-pane off seems to stop the behavior.
What is the expected output? What do you see instead?
The output is random, although usually consistent over short periods of time. For
example, several clicks may produce "TT" in a row. I think I've also seen " #" and "^F^F".
What version of the product are you using? On what operating system?
0.20.20110413 on Mac OS X 10.5.8.
Please provide any additional information below.
This behavior seemed to start after upgrading to 0.20.20110413.
Activity
Comment 1 by gnach... on April 22, 2011 16:34
I can't reproduce this on my system. Please post your ~/Library/Preferences/com.googlecode.iterm2.plist file, any tmux config file you're using, and a debug log as described here: http://code.google.com/p/iterm2/wiki/HowToReportABug
Thanks!
-
Comment 2 by clint.hep... on April 25, 2011 14:03
Although mouse-select-pane is commented out in the attached tmux.conf, I had it turned on manually for the attached debuglog. It seems that to trigger the bug, I need the following conditions:
- Two iterm2 windows, each running tmux.
- Moving the cursor from window 1 to window 2
- Clicking in window 2
It seems that output appearing in window 1 is correlated to the bug, but I could not confirm. (I had trouble producing the bug if there was no activity in either window).
-
Comment 3 by gnach... on April 26, 2011 17:47
What a strange issue. Here's what I see in the log:
Mouse down. startx=22 starty=31, endx=22, endy=31
Mouse up. startx=-1 starty=31, endx=22, endy=31
PTYTextView keyDown
writeTask:<73>
PTYTextView refresh called
Read 1 bytes: sIt shows you clicking and then pressing the 's' key, and then receiving an 's' from the host.
Does the problem occur for you on other machines?
-
Comment 5 by ryans...@google.com on January 11, 2013 14:05
I can confirm that this also happens for me. I am using gnome-terminal an xmonad and it seems to happen mostly when shifting focus away from my gnome-terminal window then clicking into a pane.
-
Comment 6 by mshir... on February 13, 2014 22:23
This happening to me as well but WHERE you click the mouse in the window is important, for me at least.
When I click anywhere to the right of the 162nd character column in the window it will start giving me random characters.
Clicking anywhere to the left of the 162nd column works as expected with no random characters.
This affects split and non-split windows.
-
Comment 11 by jdelStrot... on April 10, 2014 12:30
Hi - I just had this happened me again, although turning mouse-select-pane off had no effect - the random characters continued to be printed when I clicked or scrolled.
I think I have a way to reproduce this, or at least a similar issue. Run tmux locally, ssh into a remote tmux session,
then unplug your network and wait for ssh to time out (Write failed: Broken pipe). Once that's occurred, my local tmux window demonstrates the mouse-click/random character bug. Does that sound plausible to anyone else experiencing it? -
Comment 12 by gnach... on April 21, 2014 23:26
@jdel, that makes sense. The remote tmux turned on mouse reporting and never turned it off. Then mouse movements/clicks get reported locally to a tmux that isn't expecting it and doesn't handle it. Unfortunately this is a design flaw in mouse reporting, and no app is really able to prevent it from happening. You can turn off mouse reporting with Cmd-R.
-
Comment 13 by matthew.orior... on August 23, 2014 13:41
I have this same issue unfortunately, it is caused by a remote SSH session using tmux exiting without letting tmux turn mouse reporting off again. I could easily create a trap in bash to catch the exit and turn off mouse reporting, but I have no idea how to tell iTerm2 to turn off mouse reporting for the current session. Is it possible with a simple echo command of some sort?
-
Comment 15 by marioe... on September 08, 2014 03:38
Same here. I had the following in ~/.tmux.conf
set -g focus-events on
Steps to reproduce (running on OS X 10.9.4)
- launch iTerm2 (not tested against any nightly version, using build 2.0)
- tmux
- exit
- mvim -v (or) vi (do not specify a file)
- click on the desktop, afterwards click on the iTerm window
- mvim/vi reports E349: No identifier under cursor
The problem goes away after setting focus-events to off and restarting iTerm2. Enabling mouse-select-pane is working for me and not having any random characters.
-
Comment 17 by br...@stacklighting.com on October 24, 2014 04:39
I also experience this issue from time to time.
Mac OS X 10.9.4
iTerm2 2.0
vim 7.2I'm using standard vim within the terminal within an ssh session. Not sure how to reproduce exactly, but just found (based on the comment above), that if I go back into vim and exit, the terminal is fixed. I can then click my mouse without random control characters being spit out.
Reassigned to @gnachman
@gnachman Just for info, I get the same thing and I can confirm that Cmd-R resets the problem. So it does look like mouse reporting is the problem. It only happens when I let my remote tmux session die by closing the lid on the Macbook.
-
Fixed in commit 65556f91.
