Micro: 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.

[majonessyltetoy]

This bug didn't exist in release 1.2.0
In 1.3.0 micro print escape characters when you hold left mouse button and move the mouse cursor quickly.
It got worse in 1.3.1, then it print garbage characters when you move the mouse cursor at regular speed.

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

[majonessyltetoy]

It is related to terminal size. Default urxvt terminal size does not trigger it, but if the terminal is greatly extended then this does happen. This bug is especially annoying for people with 4k monitors.

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

[zyedidia]

Good news! The creator of tcell is implementing a fix for this that will probably be better than my hackjob. I expect this will be fixed in the next couple of days.

[ghost]

Great !

[zyedidia]

So the fix has been implemented in tcell but I have yet to update my fork of tcell. I attempted earlier but I wasn't able to get pasting to work properly (correct pasting isn't supported by vanilla tcell). Maybe I'll give this another try soon, but I'm lacking time at the moment.

[ghost]

Fair enough.

Do you think tell will ever accept your fork ? Would be optimal for all

On Sat, 21 Oct 2017, 05:59 Zachary Yedidia, [e-mail]
wrote:

So the fix has been implemented in tcell but I have yet to update my fork
of tcell. I attempted earlier but I wasn't able to get pasting to work
properly (correct pasting isn't supported by vanilla tcell). Maybe I'll
give this another try soon, but I'm lacking time at the moment.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zyedidia/micro/issues/779#issuecomment-338361901, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATuCwk8P0Mhm_Dyt_UHSzdSnXD_NqJrZks5suWw0gaJpZM4Oy6OO
.

[rcx]

This seems to happen more often when the terminal size is fullscreen. It is rarer when it only occupies half the screen but still is extremely annoying.

[blainsmith]

This is also still happening for me on build 1.3.5-dev.85-linux64. I can't seem to reproduce the steps consistently, but I think it starts happening after opening an existing file and not a new file for me. I also have the filemanger plugin installed as well.

[rcx]

Happens for any buffer on gnome-terminal. I'm surprised there is no workaround for this; it makes micro almost unusable.

[zyedidia]

The main workaround is to disable mouse support (set mouse off) 😐. I am still unable to reproduce this issue which is very annoying.

[rcx]

Maybe we can setup some debug logging to help diagnose it. Setting mouse off isn't an option to me; it's one of the main selling points for micro unfortunately.

[zyedidia]

Ok I am able to reproduce with the alacritty terminal only for wheel movements. One thing you could try would be to view the raw escape sequences with > raw. If mouse sequences are being split across events as EventKey, that's bad.

[zyedidia]

Okay I found the problem for the issue I was having and fixed it. Hopefully this fixes the issue for you. I have updated the nightly binaries so that you can test the fix if you aren't able to build from source.

[rcx]

Thank you, I will test this tomorrow.

[rcx]

I'm sorry but this still doesn't work. Here are some of the escape sequences that are getting through.
I used >raw but I couldn't find a way to escape that mode and save the output.

[<35;106;44
[<35;96;42M
[<35;99;49M
[<35;108;47
[<35;104;42
[<35;104;43
[<35;101;47
[<35;101;39
[<35;98;42M

This doesn't seem to be correlated with the speed at which I'm moving the mouse. My guess is that the second and third arguments are coordinates of the mouse. Notice how all those escapes are the same length. When the coordinates are large (3 digits), then it breaks it. It does not occur when the coordinate is 2 digits from what I have seen. Based on where I am moving around my mouse, if the x cell > 99, it seems to have problems; otherwise, it's fine.

I hope this provides some insight into the issue. I would really like to see this resolved.

[zyedidia]

Okay thanks for the update I am confident that the problem is finally fixed with the latest commit to tcell. I am recompiling the nightly binaries for you to test.

[rcx]

The fix indeed works. Awesome fix, thank you.

[zyedidia]

Great. I think this issue can be finally closed now.

[sQVe]

@zyedidia Sadly I see this problem with 1.4.0-1. I just have to move my mouse in the opened window and it starts typing MC etc sometimes. Highly annoying. Ping if I can provide you with any helpful information.

EDIT: This actually seems to only happen with my Trackball (CST L-Trac).

[DanielPower]

I've only had this happen once since 1.4.0, but I quit micro after editing and saving a file, and it pasted an escape sequence into my terminal.

It did not write any escape sequences to the file while editing, as was the previous issue. But when I closed micro, I was left with an escape sequence on my terminal that I had to backspace out.

[sQVe]

@zyedidia I switched to micro-git and compiled. Not seeing any problems with escape sequences anymore. Currently flawlessly running:

% micro --version                                                                                                                                           
Version: 1.4.1-26
Commit hash: 397c294
Compiled on February 13, 2018

I have to set my $TERM to xterm-256color and do a bunch of custom bindings for urxvt to work but that's not that big of a deal. You can find my Xresource file here: https://github.com/sQVe/kodama-dotfiles/blob/e45871937ee5ab3c352f43985429560d3a30daf3/Xresources

[DanielPower]

It just happened to me again for the second time since 1.4.0 released. I opened a file, scrolled down, selected a block of text, deleted it, and then saved the file. When I quit Micro, some escape sequences were printed to my terminal.

[daniel@daniel-arch ~]$ micro ~/.config/albert/albert.conf 
^[[<51;45;8M^[[<51;45;7M[daniel@daniel-arch ~]$ 51;45;8M51

There was a little more at the end of the last escape sequence. I started to erase it before realizing it may be useful for debugging.

I tried to revert the file to exactly the contents it had before, and make the same edit, but I did not get the escape sequences again. I am however having one other bug with this same file, and I'm not sure if it's related. When I open the file in micro, half of the time when I open this file it has full syntax highlighting. The other half of the time, only strings are highlighted.

Edit: I'm still on 1.4.0. I see there's been some changes to syntax highlighting since stable. Perhaps this issue is already fixed in the latest build.

[cs96and]

I'm seeing escape characters in the editor when using ConEmu + SSH, or ConEmu + WSL (Windows Susbsystem for Linux).

ConEmu + WSL still shows the "Pasted clipboard" message. That message does not appear with ConEmu + SSH though.

Using Putty + SSH, or Windows command prompt to WSL works fine, so this seems related to ConEmu in some way.

I'm using the latest precompiled version (1.4.0)

$ micro --version
Version: 1.4.0
Commit hash: af520cf
Compiled on January 26, 2018

[MostHated]

Sorry for the thread necro. I am getting this same issue in Tilix. I had 3 terminal windows opened (1 terminal split into 3) and one of them started doing it but not the others. I was SSH'd into my GCP server and was using Micro when it started.

micro --version
Version: 1.4.1
Commit hash: 1856891
Compiled on August 10, 2018

[Igetin]

I experienced this problem on 1.4.*, and it’s still happening on the latest release (2.0.1). It happens both locally and over SSH; whenever I’m selecting text via mouse and move the cursor down so that the view scrolls alongside the selection, escape sequences are outputted in the terminal after exiting micro. I’ve reproduced the error on both Xfce Terminal and GNOME Terminal.

I think I’ve seen escape sequences get printed in some other cases too, but I couldn’t come up with anything else right now.

$ micro --version
Version: 2.0.1-dev.26
Commit hash: 7c71995
Compiled on February 12, 2020
$ xfce4-terminal --version
xfce4-terminal 0.8.7.4 (Xfce 4.12)
$ gnome-terminal --version
# GNOME Terminal 3.28.2 using VTE 0.52.2 +GNUTLS -PCRE2

[dittoslash]

Scrolling down and moving mouse around simultaneously rapidly deletes the whole buffer.

$ micro --version  
Version: 2.0.1  
Commit hash: 7c1995  
Compiled on Feburary 12, 2020  
$ urxvt -h 
rxvt-unicode (urxvt) v9.2.2 - released: 2016-01-23   

[rcx]

This seems to be happening still in ConEmu on WSL :(
Very interestingly, even after I close micro escape sequences get written to the terminal when I move my mouse until I restart ConEmu. So it may be a bug in ConEmu?

[rcx]

One cause of this issue is likely to do with terminal emulators with buggy any-event mouse-mode support. This includes ConEmu. The workaround is to avoid setting that mode (ANSI escape 1003). For those users I have created a workaround that you can install here.

[cumsuckingfuckslut]

Happens also on 2.0.6. For me steps to reproduce are:

1. Open terminal of choice (Alacritty in my case)
2. SSH to a remote server
3. Open some file with micro
4. Wait until SSH connection dies (packet_write_wait: Connection to xxx.xxx.xxx.xxx port 22: Broken pipe)

After the SSH connection ends, the terminal buffer is not cleared, and all mouse events output escape sequences. CTRL + C does not clear this, so the only thing I know to fix this is restart the terminal window.

[zyedidia]

Does this happen with an editor like Vim as well (make sure that mouse tracking is enabled in Vim)? Given your description, it sounds like the broken pipe killed micro, and micro wasn't able to reset the terminal mode properly, leading to an incorrect terminal state (mouse tracking should not be enabled in general).

I've just run some tests when running kill and kill -9 on micro and Vim, and in both cases micro doesn't reset the terminal state properly, whereas Vim properly resets it for kill. I think it should be possible to intercept the terminate signal and shut down properly, which may also fix the broken pipe issue.

To be clear, this issue describes mouse sequences being written into the micro buffer, not into the terminal after micro has closed, and I believe this issue is truly fixed at this point. For that reason, I'll close the issue now, and also update back when I have implemented the terminate signal handling.