New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escape sequences written on mouse movement #779

Open
TedSinger opened this Issue Aug 10, 2017 · 73 comments

Comments

Projects
None yet
@TedSinger
Contributor

TedSinger commented Aug 10, 2017

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

This comment has been minimized.

majaha commented Aug 19, 2017

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

This comment has been minimized.

Contributor

TedSinger commented Aug 20, 2017

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 comment has been minimized.

Contributor

DanielPower commented Aug 21, 2017

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

This comment has been minimized.

majaha commented Aug 21, 2017

@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 comment has been minimized.

majonessyltetoy commented Aug 27, 2017

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

This comment has been minimized.

Contributor

TedSinger commented Sep 2, 2017

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

@ghost

This comment has been minimized.

ghost commented Sep 4, 2017

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

This comment has been minimized.

majonessyltetoy commented Sep 4, 2017

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

This comment has been minimized.

Owner

zyedidia commented Sep 5, 2017

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

This comment has been minimized.

Contributor

DanielPower commented Sep 5, 2017

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

This comment has been minimized.

Owner

zyedidia commented Sep 5, 2017

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

This comment has been minimized.

Contributor

TedSinger commented Sep 5, 2017

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

This comment has been minimized.

ghost commented Sep 5, 2017

Ubuntu 16.04.1 with micro 1.3.1

@DanielPower

This comment has been minimized.

Contributor

DanielPower commented Sep 5, 2017

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

This comment has been minimized.

Owner

zyedidia commented Sep 5, 2017

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

@majonessyltetoy

This comment has been minimized.

majonessyltetoy commented Sep 5, 2017

Snap binary.

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

@DanielPower

This comment has been minimized.

Contributor

DanielPower commented Sep 5, 2017

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

@ghost

This comment has been minimized.

ghost commented Sep 5, 2017

Binary from the release page.

@majaha

This comment has been minimized.

majaha commented Sep 5, 2017

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

This comment has been minimized.

Contributor

DanielPower commented Sep 5, 2017

@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

This comment has been minimized.

majaha commented Sep 6, 2017

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

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Sep 6, 2017

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

This comment has been minimized.

Owner

zyedidia commented Sep 6, 2017

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

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

@ghost

This comment has been minimized.

ghost commented Sep 6, 2017

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

@majonessyltetoy

This comment has been minimized.

majonessyltetoy commented Sep 6, 2017

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

This comment has been minimized.

Contributor

DanielPower commented Sep 7, 2017

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

This comment has been minimized.

ghost commented Sep 13, 2017

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

This comment has been minimized.

Contributor

DanielPower commented Sep 13, 2017

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 comment has been minimized.

Owner

zyedidia commented Sep 13, 2017

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?

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Sep 17, 2017

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

This comment has been minimized.

Ragnoroct commented Sep 22, 2017

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 zyedidia added the bug label Sep 24, 2017

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Sep 24, 2017

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.

@gedw99

This comment has been minimized.

gedw99 commented Oct 18, 2017

Great !

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Oct 21, 2017

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.

@gedw99

This comment has been minimized.

gedw99 commented Oct 21, 2017

@ecx86

This comment has been minimized.

ecx86 commented Jan 18, 2018

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 comment has been minimized.

blainsmith commented Jan 22, 2018

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.

@ecx86

This comment has been minimized.

ecx86 commented Jan 22, 2018

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

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Jan 23, 2018

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

@ecx86

This comment has been minimized.

ecx86 commented Jan 23, 2018

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

This comment has been minimized.

Owner

zyedidia commented Jan 23, 2018

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 added a commit to zyedidia/tcell that referenced this issue Jan 23, 2018

Use more conservative alt-key detection
Occasionally terminals can send `\x1b[` which previously was being
treated as `Alt-[`, but this could also be the start of a mouse or
other escape sequence. After this update, tcell will wait for 200
milliseconds more when it finds a conflict to give the terminal
time to send more characters. This does result in a slight delay
when pressing a conflict key (only `Alt-[` to my knowledge) and
this means that tcell polls every 200 milliseconds which isn't
ideal.

Ref zyedidia/micro#779
@zyedidia

This comment has been minimized.

Owner

zyedidia commented Jan 23, 2018

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.

@ecx86

This comment has been minimized.

ecx86 commented Jan 23, 2018

Thank you, I will test this tomorrow.

@ecx86

This comment has been minimized.

ecx86 commented Jan 24, 2018

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

This comment has been minimized.

Owner

zyedidia commented Jan 24, 2018

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.

@ecx86

This comment has been minimized.

ecx86 commented Jan 29, 2018

The fix indeed works. Awesome fix, thank you.

@zyedidia

This comment has been minimized.

Owner

zyedidia commented Jan 29, 2018

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

@zyedidia zyedidia closed this Jan 29, 2018

@sQVe

This comment has been minimized.

sQVe commented Jan 30, 2018

@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

This comment has been minimized.

Contributor

DanielPower commented Jan 31, 2018

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.

@zyedidia zyedidia reopened this Jan 31, 2018

@sQVe

This comment has been minimized.

sQVe commented Feb 13, 2018

@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

This comment has been minimized.

Contributor

DanielPower commented Feb 19, 2018

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

This comment has been minimized.

cs96and commented Jun 6, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment