Escape sequences written on mouse movement

[TedSinger]

When I ssh into an AWS EC2 instance and use micro, mouse movement inserts nonsense text. Here is a sample: M@4![M@N"][M@2"][MCH"MC2!&!MC3!<"[MC+MCC+9)MC=#MCe&[MCo'[MCo" Usually, that terminal will freeze after a little of this - sometimes as little as 20 characters, sometimes over 100. I can kill micro from a separate process, but then that frozen terminal keeps inserting mangled control codes for all mouse movement and ignores any keyboard input - even after the ssh session is killed. Normally, I'd say this has to be a terminal emulator bug, but the same happens in both Terminator and Xfce Terminal. I couldn't reproduce it with joe, another console editor with mouse support.

I've reproduced this with ssh -X, -x, and -Y. It happens on both the EC2 instance itself and a docker container (see Dockerfile below) running on that instance. It does NOT happen on localhost, even when ssh'ing into a docker container running on localhost.

Commit hash: dd5afc0 (v1.3.1 release) OS: Ubuntu 16.04 Terminal: Terminator, Xfce Terminal

$ cat Dockerfile FROM ubuntu:16.04

RUN useradd ted RUN echo 'ted:<appropriate stuff from /etc/shadow>' | chpasswd -e RUN usermod -a -G sudo ted RUN mkdir /var/run/sshd RUN mkdir /home/ted RUN chown -R ted /home/ted RUN apt-get update

RUN apt-get install -y openssh-server EXPOSE 22 CMD ["/usr/sbin/sshd", "-D"]

Once inside the container, download and unpack micro, invoke it with no arguments, then move the mouse.

[majaha]

Does it happen with all mouse movement, or only if you wiggle the mouse around a lot? I have an issue that might be related but sounds like it might not too, I don't know whether to create a new issue or post in the comments of this one.

[TedSinger]

It happens immediately with any mouse movement. I suspect it isn't a bug in micro, but in some discrepancy between the local and remote termcap info.

[DanielPower]

This is happening to me on the latest nightly even without SSH. Moving the mouse quickly outputs garbage like: 13M[<35;46;15M[<35;37;13M[<35;22;11M[<35;58;11M[<35;47;13M[<35;49;15M

Note: This only occurs when moving the mouse quickly. Moving the mouse slowly has no effect.

xfce4-terminal commit hash: d70a48b

[majaha]

@DanielPower This sounds like the issue I'm having. I've been digging around in the source a bit but I'm no Go expert.

I think it's something to do with buffer overflow on an event channel or something, some of the escape sequence is left out and the rest is inserted as text maybe.

[TedSinger]

Confirmed that the bug does not occur for me (over ssh or otherwise) in 1.2.0

[ghost]

This happens to me as well when using xfce4-terminal or xterm, but not urxvt. One important detail is that at the bottom of the editor it says "Pasted clipboard" when this happens.

[zyedidia]

I know the change that likely introduced this bug from 1.2 to 1.3 but I am not experiencing this bug myself, even on a huge monitor over ssh. Are you sure this is happening on the latest nightly (it should have even been fixed in 1.3.1 not gotten worse). Make sure you know what version you are using (micro -version).

[DanielPower]

Issue still occurs on the latest nightly d41a255. Happens on local sessions. SSH is not required to reproduce the bug.

Example output: [<35;36;14M[<35;28;12M[;11M[<35;13;12M[<35;26;13M[<35;42;10M[<35;51;11M[<35;40;10M]]]]]]]]

Terminal: xfce4-terminal and mate-terminal

[zyedidia]

I am still unable to reproduce :( even when using both those terminals on SSH or locally. What operating system are you using? I've been testing with Ubuntu 16.04.2.

[TedSinger]

Seems like there's two different sets of symptoms here. I see my problem with 1.3.1, not 1.2; in xfce4, Terminator, and urxvt; immediately on any mouse movement, with default terminal size. Linux Mint 17/18 local, and Ubuntu 16.04 remote. I sometimes get the "Pasted Clipboard" status. I guess I am getting a Ctrl+V code by coincidence?

[ghost]

Ubuntu 16.04.1 with micro 1.3.1

[DanielPower]

Archlinux 64bit with Micro 1.3.2-dev I also sometimes get the "Pasted Clipboard" status.

I don't know if it's related, but my vte3 package is version 0.48.3. Perhaps @zyedidia is running an older version? I don't even know if that would be related, but I figure it's worth mentioning.

[zyedidia]

Have you guys been building from source or downloading the binaries from the releases page?

[majonessyltetoy]

Snap binary.

Version: 1.3.2-20 Commit hash: d41a255 Compiled on September 05, 2017

[DanielPower]

I've tested on multiple nightly binaries. I have not compiled from source.

[ghost]

Binary from the release page.

[majaha]

I get this on v1.2.0 I compiled myself, as well as v1.3.1 binary, on ARM. I also see "Pasted Clipboard".

[DanielPower]

@majaha, can you provide the commit hash of your 1.2.0 build of Micro? I cannot reproduce the issue on 1.2.0 stable from the releases.

use micro --version to get the commit hash and version.

[majaha]

@DanielPower Commit hash: be81241, compiled on ARM. Oddly, the bug seems to behave a little differently when micro is run inside tmux.

[zyedidia]

I'm still not sure what the problem is and I still haven't been able to reproduce the bug, but I think gdamore is going to address the issue in tcell in a better way than I have. Hopefully the fix will come soon.

In the mean time, with the most recent commit you can disable mouse support with set mouse off.

[zyedidia]

Update: I recently made a commit to tcell that may have fixed this issue. I have updated the nightly binaries so that you can test if you were using those. Make sure you are using hash ab242c5b1789f9c5c1de6bcb4338d1ede2ec0624.

At the very least it shouldn't say Pasted clipboard at the bottom.

[ghost]

Nope. Still happening for me. EDIT: Yes, I'm on the correct hash, and "Pasted clipboard" is gone

[majonessyltetoy]

Still occurs in ab242c5. "Pasted clipboard" is gone from gnome-terminal, but has started to appear in urxvt (but that's probably because urxvt froze before it could show it in previous versions, so it's getting better).

By the way, really impressive that changing a setting in the program updates the config file. Great design philosophy.

[DanielPower]

Still occurring for me as well in ab242c5. I no longer get the clipboard pasted message, but I still get the garbage output.

[<35;38;13M[;11M[<35;45;14M[<35;11;1M[<35;29;13M[<35;50;12M[<35;43;13M[;12M[<35;41;12M[<35;40;11M[<35;31;11M]]]]]]]]]]] This is the output of simply opening an empty file in micro, and moving the mouse around in circles a few times.

[ghost]

I too have the issue. The output I get on mouse movement is very similar to DanielPower's.

micro --version Version: 1.3.2-38 Commit hash: 612658d Compiled on September 13, 2017

Fresh Arch Linux install as of Aug 12, installed from AUR. This happens in Terminator, xterm, and Tilda. I'm not using byobu, screen, or any other multiplexer. It says "Pasted Clipboard" whenever it happens.

EDIT: I have followed the workaround by building the latest commit and disabling mouse support via set mouse off . Good enough solution for me.

[DanielPower]

Disabling mouse support is not a good enough solution for me. I use micro because of its great mouse support, and it has worked fine until 1.3.1.

Has anyone determined what changed between 1.3.0 and 1.3.1 to break this? Also, the title of this bug should be changed, since it is not related to ssh.

[zyedidia]

This really confuses me. I just installed arch linux with xfce4 to test this and I only see an issue with 1.3.0 and even then you have to move the mouse very fast to see anything. I don't see any problems for 1.2.0, 1.3.1 or 1.3.2-dev.38. I have tested with the default terminal and with terminator with a terminal size as large as 211x52.

Are you using a much different terminal size?

[ghost]

It happens regardless of the terminal size I use. I'm using the i3 WM and no DE, in case this is relevant.

[ghost]

Perhaps it's differences in mouse DPIs? I have a mouse DPI of 1800 set, I believe.

[DanielPower]

@zyedidia I appreciate the effort you're putting into finding the issue. It's really weird that it's not reproducable on your system.

Attached is a video of the issue occuring on the latest nightly. As you can see, the faster the mouse movement, the more likely escape sequences are to appear.

Edit: The low framerate is just the gif. My cursor isn't actually 'teleporting' as it appears in the gif.

I'm back to school now, so I have less time for testing, but I will try sometime this week to test commits between 1.2.0 and 1.3.0 to find out exactly which commit introduced the issue.

[ghost]

I do also want to note that this does not occur solely through SSH on my system - it happens on my local terminals as well; both Terminator and Tilda.

[zyedidia]

I know what change introduced this problem, but I have to think about how best to fix it because it's a change that I made in tcell (the root of the problem comes from this commit in tcell: https://github.com/zyedidia/tcell/commit/60e2a28eba7ec8f15907ca7cd661badcbbab271a) but I am not an expert with tcell and I'm not sure exactly why the bug is happening.

[zyedidia]

I have just made a change that I am hoping will fix this issue, but I am not sure (because I can't reproduce it). Please let me know if it was fixed for you (feel free to also let me know here or in gitter chat if you prefer that). I have just updated the nightlies to reflect the change (they are also now being compiled with go 1.9).

[ghost]

Just tested on xfce4-terminal, urxvt, and xterm and it's fixed.

[DanielPower]

@zyedidia, you're amazing! No more escape sequences on mouse movement. The issue is fixed on my machine as well :)

[zyedidia]

Alright great it seems like this has been fixed.

[majonessyltetoy]

Hate to be that guy, but it's still happening. It has gotten a lot better, but now it's prone to freezing on mouse movement. If you type and move the mouse it'll still print escape characters. In the example micro freezes at the end.

Commit hash: f7238e8

[DanielPower]

Weird, I'm completely unable to reproduce this with the latest commit. Even by moving the mouse rapidly while typing as in your example.

What terminal are you using?

[majonessyltetoy]

Gnome-terminal 3.24.2 using VTE version 0.49.1 Terminator 1.91 does not print escape characters, but freezes. Urxvt freeze on just mouse movement, printing MC or MCMC. But also exhibit the same typing and mouse movement escape characters as above.

[zyedidia]

Try giving it a go now. I gave it a longer delay so maybe it will be better.

[DanielPower]

If this is being based on a delay, doesn't that mean it will affect slower systems more than faster systems? Even if you increase the delay, wouldn't that mean that a system under heavy load (for example, while compiling) might experience this issue?

Is there some other way to ensure the escape sequences are completed other than to use a timer? It just seems like a hack rather than a solution.

In fact, the issue is even worse if it happens rarely, since someone may not notice that an escape code got printed into their file (for example if it happens while scrolling). That user will now have a broken file, and not know why.

[zyedidia]

You're right that it shouldn't be solely based on a delay. The problem that causes this issue is that sometimes the terminal doesn't send a full escape sequence before tcell reads it and so an incomplete escape sequence is read (such as a mouse sequence without the escape character) and micro thinks it's the user typing and inputs the characters into the file.

The incorrect solution before my recent update was just to have tcell pause for 10ms to let the terminal send the full escape sequence. This worked well on my computer but obviously not for others.

Now the system is more robust because it tracks whether it has an incomplete sequence or not and waits for the next read. There was a bug though that allowed it to freeze (which I was mostly able to reproduce).

I have just added another commit which should fix that bug and rebuilt the nightlies for anyone to test.

[majonessyltetoy]

That fixed it. Great work!

[zyedidia]

Great I'll close the issue then, and hopefully it's fixed for good (let me know if you have more problems).

[majaha]

Unfortunately I'm still getting this problem :( On a raspberry pi through ssh: http://recordit.co/6P3DC8quLw

[TedSinger]

I am still getting the problem through ssh, but 1) Much less. Only moderately fast movement does it. Before, it was any movement or click. 2) The text entered looks different. Hard to describe the difference. 3) Previously, the nonsense entered was often escape sequences, which invoked random commands (I believe that was the cause of the "Pasted Clipboard" message we often saw). Now, I only see micro commands being invoked if I move the mouse unrealistically fast. Commit hash: 2f587c6 (1.3.2 release)

Also, I've realized that the problem does not happen (with any version of micro) using my chromebook as the ssh client - Termux running on ChromeOS.

[majaha]

@TedSinger Were you using a touchpad on your chromebook? It sounds crazy, but I can only reproduce when I'm using my mouse, not my touchpad. Maybe it's just because I can move the mouse faster?

[TedSinger]

Yes, the chromebook is with a touchpad. But for 1.3.1, any mouse movement at all would trigger the bug, so it didn't seem related to cursor speed.

[zyedidia]

The only way I can imagine that this issue is still happening is if the terminal is splitting the escape sequence at the escape character.

For example, the terminal is trying to send \x1b[<32;37;13M which is a mouse movement event, but it splits it up and on the first read call micro receives \x1b[ and on the next read call micro receives <32;37;13M. So before the second read call micro parses \x1b[ which is the escape code for Alt-[, so micro thinks that the terminal is saying that the user pressed Alt-[, so it executes the keybinding if it exists. Then micro reads the next sequence, and thinks the terminal is saying that the user typed the characters <32;37;13M, so it inserts those characters into the document. I suppose this could be fixed by simply not allowing Alt-[ to be a valid keybinding.

If my theory is correct, then you should see strings like <32;37;13M being inserted (without a [ at the beginning). Please let me know if you are seeing different strings like [<32;37;13M instead.

EDIT: Actually you should see [<32;37;13M if you haven't bound Alt-[. Try binding Alt-[ (for example > bind Alt-[ CursorDown). Then when you experience the issue, if my theory is correct, the cursor should move down and then something like <32;37;13M should be inserted. If that is indeed the behavior you see, then I will disallow Alt-[ as a binding, and the issue will hopefully be fixed.

[Ragnoroct]

I'm having a similar problem on On Raspbian Pi Arm7 Stretch Using ssh Using wsl mintty (windows 10 bash) terminal/emulator

Version: 1.3.3-dev.6 Commit hash: cb75531 Compiled on September 22, 2017

It happens when I try to Shift-RightClick to paste through the terminal. I would get an output similar to

Version: 1.3.3-dev.6
3  [<35;42;11MCommit hash: cb7553
4 Compiled on September 22, 2017

After each consecutive paste the rightmost number would go up [<35;42;12M

I think I've somehow killed it too because micro freezes (cursor still blinks) and I can't exit or anything.

It didn't freeze when I switch to git-bash but it still pastes the weird characters.