Mouse interactions do not appear to be working properly on windows

[zacps]

Original issue by @dparnell

Which operating system does the issue occur on?

Windows 10 client connecting to a Linux 16.04 machine via ssh

Steps to reproduce:

1. Make sure that dialog is installed
2. Execute dialog --yesno Testing 10 30
3. Attempt to use the mouse to click on either the Yes or No button. Nothing happens

Expected bahavior:

Clicking on either of the buttons should cause the dialog process to exit

[zacps]

From @parthsdoshi

Here's a test case that works using cmd.exe but not with alacritty.exe:

1. Run bash
2. Run tmux
3. Make sure tmux mouse mode is on: <Leader> :set -g mouse on
4. Run dialog --yesno Testing 10 30
5. Verify clicking works using cmd.exe
6. Detach tmux: <Leader> d
7. open alacritty.exe
8. Run bash
9. Run tmux a
10. Run dialog --yesno Testing 10 30
11. Verify the same does not work in alacritty.

There's a few simpler test cases too.
Open bash through cmd.exe and test vim scrolling. Do the same in alacritty.exe and see that vim won't receive any mouse input.

[kumarharsh]

I've found that scrolling in Alacritty scrolls the whole alacritty buffer. So if I'm running tmux, the tmux panes themselves scroll off-view when I scroll in any pane.

I then opened ConEMU and attached to the same tmux session, and I am able to scroll in the vim editor pane. It still doesn't scroll in panes which have other programs (say webpack, etc) running in them. The whole screen doesn't scroll like alacritty, but the tmux pane hovered over receives the mouse events and starts outputting ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A characters instead of scrolling.

If I launch wsl directly (Run > wsl.exe), and attach the same tmux terminal in wsl using tmux attach, I am able to use the mouse to scroll in the correct pane.

[mqudsi]

Yes, that's to be expected because the scroll event is not being sent to the application, only to the terminal's pager.

[mqudsi]

Perhaps @zacps or a team member can update the original issue with a link to this, which I suppose can be considered the upstream issue: microsoft/terminal#376

@DHowett-MSFT has explained why this doesn't work (it's a ConPTY thing, nothing to do with alacritty one bit)

[malaverdiere]

This is happening to me with enable_experimental_conpty_backend set to both true and false. So maybe this is more than a ConPTY issue.

[mqudsi]

@kumarharsh that's because wsl.exe (and bash.exe) is not a conpty process.

[kumarharsh]

Yeah, I kinda realised that just after posting, so I deleted my comment to prevent confusion (sorry about that)

[llinfeng]

I find mouse clicks to be accepted for WSL-tmux (on Windows) via wsltty. Source: microsoft/terminal#545 (comment)

Are there special settings for alacritty to enable such mouse features? On wsltty, I even found mouse-clicks to be working for SSH sessions.

[chrisduerr]

Are there special settings for alacritty to enable such mouse features?

No, the shell is likely just not sending/accepting the right escapes.

[unphased]

To confirm, mouse is just not working yet in alacritty on windows? I can only select with it.

[kchibisov]

Ehm, what else do you want from it? Are you talking about mouse mode? The thing that interacts with apps like htop, tmux with (set mouse on), etc.

[unphased]

@kchibisov yes that's what I meant, sorry.

[kchibisov]

Could you try running this echo -e "\e[?1000h". and after that clicking with your mouse. it should paste random garbage.

P.s. I'm not sure whether windows has echo -e thing, but you should get an idea on what to do.

[DHowett-MSFT]

If Alacritty is using the windows pseudoconsole infrastructure (not wsltty(!)), you're still subject to the limitations mentioned in microsoft/terminal#545 (comment). The system-level support for translating mouse events isn't there just yet. 😄

[kchibisov]

I've just found out a link to a thread, thx @DHowett-MSFT .

[tcneuen]

Latest version of MS terminal infrastructure has been updated to handle mouse events
microsoft/terminal#545

[DHowett-MSFT]

Just so you're aware: the console host changes here will be released in an upcoming version of Windows (probably not the most immediate one if the build number is <19500), and the changes we made do not support mouse events for Windows applications.

For anyone working on a terminal: The pty hosting infrastructure now hooks the terminal's input stream directly to the application's input stream; there's no more input translation in the "pure VT" case.

We still have a lot of work to do to synthesize windows mouse events for windows applications where we do need translation, but this may be enough to unblock other ConPTY consumers.

[kchibisov]

@DHowett-MSFT

So If I understand you correctly, if we have perfectly working mouse mode on all platforms except Windows(due to Windows), after this update things should work right away in ConPty for us?

[DHowett-MSFT]

Yes, if the application on the other end is in VT input mode (so is running in WSL, newer versions of Cygwin/MSYS2, or otherwise using the ENABLE_VIRTUAL_TERMINAL_INPUT handle mode as a Win32 application.)

[kchibisov]

Ok, thank you.

[Hasanabbas]

Yeah I read a bit more on it and realised this. Oh well

[jostaub]

may help some people:
i made a branch which integrates #4501 from fredizzimo and commit 8d2d1eb from aytey
which replaces "\r\n" with "\n" based on version 0.10.1

[kirawi]

Wezterm has also compiled the fixed version of conpty: https://github.com/wez/wezterm/tree/main/assets/windows/conhost

[evertonse]

I also have mostly switched over to use the Neovim built in terminal through the Neovide GUI, so I don't use Alacritty that much anymore.

It worked, thank you very much. I'm on windows 10 22h2.
I did almost exactly that.
I've build your branch https://github.com/fredizzimo/alacritty/tree/add_openconsole_support
Then i got the conpty.dll and OpenConsole.exe from WezTerm build, copied into the alacritty.exe folder
and it simply worked, idk what you did, but thank you.

As I'm not willing to got to W11 just now, and Alacritty is actually faster then Wezterm (on my machine it seems that way)
That saves me a lotta trouble. Thank you

[kchibisov]

Yeah, performance on windows is bottle necked on ConPty. Even macOS alacritty is 10-100x faster than windows build, simply because conpty is too slow.

[anupamsr]

I understand this issue is closed, but just for those who came looking like me, I have added a PR to update https://github.com/fredizzimo/alacritty/tree/add_openconsole_support to current master

[smprather]

I can't believe these guys are abandoning Win10 users. I'm stuck on a Win10 corp laptop, like many of us are. Just wanted to tag the thread that as of 10/1/23, the above work-around still works. I used @anupamsr 's fork. Looks like it had too many conflicts to merge into @fredizzimo 's fork (but I'm not GitWizard). Thanks!

[kchibisov]

@smprather it looks like you haven't looked into forks much or patches related. The required patches are merged and loading conpty.dll is supported on master.

[smprather]

@kchibisov Yeh, I'm a Git dunce. There can be no doubt. So to be clear: What's the best route for me to take to get latest Alacritty w/ mouse working on Win10?

[kchibisov]

build from master and add conpty.dll/OpenConsole.exe in the path.

[smprather]

Ok, built from master. I had conpty.dll/OpenConsole.exe (that I got from WezTerm) in the same dir as the fresh alacritty.exe (C:\Program Files\Alacritty). Tried it, but I was getting a freeze-up after tmux attach. So I name-changed them "out of the way" (added _ to names), re-ran Alacritty, and now everything works perfect. Including an ssh from WSL to another machine running tmux. Thanks @kchibisov / @fredizzimo / @anupamsr ! (Note: I'm getting an occasional freeze-up. It's not a huge deal since I work via tmux, so I just close Alacritty and re-launch. I'm assuming it is unrelated and will be resolved eventually.)

[smprather]

Nope. The freeze-up only takes a minute or two of working to kick in. Hopefully it is resolved soon. Looks like I'm back to KiTTY again :(. Maybe I'll give WezTerm a shot.

[kchibisov]

just try older commits.

[smprather]

Energy is running too low to throw darts in the dark. I may try again next weekend. Even though @fredizzimo 's fork is way out of date, it actually works pretty good (mouse works, no freezes... so far). I'll probably be missing some new things like undercurl, OSC-52, etc. But I can tough it out till master stabilizes.

[anupamsr]

Use this one. I have been maintaining it for quite some time, though stopped around 4 months ago. I can update it if essential. https://github.com/anupamsr/alacritty/tree/add_openconsole_support

[smprather]

I think I tried that one last night and it didn't work. I'll try again and let you know. Definitely not "essential". This whole quest started when I saw LazyVim mention "undercurl". I think that's pretty good evidence of low-prio 😄.
I opened a separate issue on master branch freezing #7261 . Except for the freeze, it was working well.

[kchibisov]

I really don't understand this fuss with forks when the patch is upstream the way it was. it's all just dll loading in the end of the day, nothing special is required. Right here

alacritty/alacritty_terminal/src/tty/windows/conpty.rs

Line 49 in ace987f

match Self::load_conpty() {

It's likely just something got borked niside the upstream winit update. Just bisecting alacritty is more than enough to get this fixed, etc. Or maybe posting the --print-events output.

[kchibisov]

And be aware that all features are basically tied to those dll libs, if they update to have undercurl, alacritty will have all of that automatically, because conpty basically is a multiplexer and it filters out everything it doesn't understand.

[smprather]

I'm an electrical engineer, not a sw-dev. I can, and will, bisect to find the freeze-up commit. But I'm a git-dunce, so first, I'll have to figure out how to efficiently bisect. Then, each iteration is a 5 minute build followed by a few minutes of running to if freeze happens (I haven't identified the pattern yet). And these iterations must happen via awful Windows CLI environment. So that's another source of friction. I will get it done though.

[smprather]

I came for the undercurl, but I'm staying for the speed. Even working via a horrible 150ms ping to my ssh servers in Sweden, the GUI speed-up vs. KiTTY is non-negligible when doing nvim scrolling, tmux window cycling, etc.

[anupamsr]

I really don't understand this fuss with forks when the patch is upstream the way it was. it's all just dll loading in the end of the day, nothing special is required. Right here

alacritty/alacritty_terminal/src/tty/windows/conpty.rs

Line 49 in ace987f

match Self::load_conpty() {

It's likely just something got borked niside the upstream winit update. Just bisecting alacritty is more than enough to get this fixed, etc. Or maybe posting the --print-events output.

There is one old patch that adds support for openconsole (https://github.com/fredizzimo/alacritty) which was working well but it wasn't updated. I updated it and submitted the patch (fredizzimo#1). Neither my patch nor the old patch were merged. Later it borked because of winit which I also fixed if I remember correctly.

The reason I have not updated it in last 4 months is because there was a parallel commit done to the alacritty master achieving the same thing, which told me that noone has bothered to actually look at my repo that I had been maintaining.

For those who still want to work on Windows 10 like I do, I suggest to just clone my repo.

[kchibisov]

@anupamsr you're free to submit what you think is missing upstream, but the @fredizzimo patch was picked up and merged here #6994 . Windows support won't get better until folks can provide patches for it, because barely no alacritty contributors are developing on windows.

[tfriedel]

I just spent a rather long time figuring out this issue. I have it solved now thanks to the tip to copy conpty and openconsole to alacritty. I'd recommend to bundle them with alacritty on Windows, as no doubt many other people will either never figure this out or waste their time.

[abdenourgnx]

Hello @tfriedel, well i went all the way down to find your comment. can you briefly explain how you managed to make it work? thank you.

[tfriedel]

@abdenourgnx
Sure!

1. Go to https://github.com/wez/wezterm/tree/main/assets/windows/conhost and download OpenConsole.exe and conpty.dll
2. Put these files into your alacritty program directory (e.g. c:\Program Files\Alacritty\ )

That's all! Alacritty will find these files and use them. (Unless you explicity disabled the conpty feature by setting winpty_backend to True)

[abdenourgnx]

@tfriedel Like magic. Thank you for saving me from hours of pain.

[1812-Ram]

@tfriedel Thanks mate!! work as treat!!