Skip to content
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

[Terminal] VT Mouse Support #545

Closed
cerebrate opened this issue May 8, 2019 · 44 comments · Fixed by #4859
Closed

[Terminal] VT Mouse Support #545

cerebrate opened this issue May 8, 2019 · 44 comments · Fixed by #4859
Assignees
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@cerebrate
Copy link

cerebrate commented May 8, 2019

  • Your Windows build number: (Type ver at a Windows Command Prompt)

10.0.18890.1000

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

I routinely use mouse mode in tmux with WSL for window selection, pane resizing, and scrollback, enabled in tmux.conf thus:

  # -- mouse support ---------------------------------------------------------                                                                                                                                                                                        
  # Enable mouse control (clickable windows, panes, resizable panes)                                                                
  set -g mouse on

While this works perfectly in conhost, it does not work at all in Terminal; nothing happens, as if the mouse events were never reaching tmux.

  • What's wrong / what should be happening instead:

tmux mouse support (and presumably other mouse-supporting applications) should work as they do in conhost.

@zadjii-msft zadjii-msft changed the title tmux mouse support not functioning in Terminal [Terminal] VT Mouse Support May 8, 2019
@zadjii-msft
Copy link
Member

Yea, this is a known issue at the moment. We need to add support for mouse in two places: both in the terminal, to be able to synthesize mouse sequences, and in conpty to be able to read mouse sequences.

This issue is tracking the first bit, the Terminal functionality.

For the second bit, the conpty part, see #376.

@zadjii-msft zadjii-msft added this to the Windows Terminal v1.0 milestone May 8, 2019
@zadjii-msft zadjii-msft added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label May 8, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-VT Virtual Terminal sequence support Product-Terminal The new Windows Terminal. and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added the Area-Input Related to input processing (key presses, mouse, etc.) label May 17, 2019
@guibirow
Copy link

Sadly this does not work, having the mouse events with TMUX would defer the need to have multiple panes.
I hope this feature get implemented before the panes, is much needed and will solve most of issues

@jgkawell
Copy link

I would like to point out that the mouse support is also not supported in tmux within Docker (through Powershell). I know this is because the functionality simply isn't there in Terminal so of course it won't work in WSL or Docker, but thought I'd go ahead and mention it.

@guibirow
Copy link

guibirow commented Jun 28, 2019

the mouse does work with TMUX in WSL

@kumarharsh
Copy link

Mouse works with wsltty: https://github.com/mintty/wsltty

@jgkawell
Copy link

@guibirow Maybe it's an issue with Docker from within Terminal then.

@kumarharsh
Copy link

No. It's not an issue with Docker. It's an issue with conpty (this repo). Try wsltty if you want mouse support.

@jgkawell
Copy link

Are there plans to enable full mouse support in tmux for Docker in the future through Terminal?

@kumarharsh
Copy link

kumarharsh commented Jun 28, 2019

I don't know about Docker specifically, but i don't see why it should be any different than a normal terminal. This issue is about that, so keep an eye out!

@jgkawell
Copy link

jgkawell commented Jun 28, 2019

So I just checked tmux through WSL 1 in Terminal and the mouse isn't supported there either. So my guess is that tmux itself just doesn't work in Terminal at this point and that it's not a Docker issue. Not sure what @guibirow was seeing on his end.

@guibirow
Copy link

guibirow commented Jun 28, 2019

You have to run a command to enable it, isn't enabled by default.
I don't have it right now, but it is simple like this set mouse on
I will have to confirm next week when I get my laptop

It only works on wsl terminal though, not in the new windows terminal

@jgkawell
Copy link

Oh I gotcha. Yeah it works fine in the plain WSL window. It only fails to work when embedded within the new Windows Terminal.

@egmontkob
Copy link

If you implement mouse support, please make sure to implement the SGR (1006) extension as well.

The legacy, byte-based protocol only allows row and column numbers up to 223, because 32 is added to this number and this is sent as a single byte. The column limit is not uncommon to be too small. (By the way, beginning at column 95 the generated data is not 7-bit clean and not valid UTF-8 which is a problem for encoding conversion layers such as luit.)

The SGR 1006 extension fixes these problems by encoding the numbers as decimal digits, and is supported by plenty of applications.

If this extension is not requested, please don't generate any event if the row or column exceeds 223. Otherwise an overflow could have nasty consequences. E.g. clicking on column 227 could generate the byte 32+227 = 259 = 3 = Ctrl+C which is typically the interrupt character sending a SIGINT to the running process.

@DHowett-MSFT
Copy link
Contributor

So! Conhost actually does support DECSET 1006! Since we have this intervening layer (the pseudoconsole, which needs to talk to conhost), we get to choose what sort of mouse mode the pseudoconsole requests and supports. I see no reason that that shouldn't just be 1006 😄 Thanks for the info!

@DHowett-MSFT
Copy link
Contributor

DHowett-MSFT commented Jul 9, 2019

To clarify, because we have conhost in the middle, that would look like this:

                                      +-----------------+
                                      |                 |
                 DECSET 1002, 1005    | Windows conhost |
+-------------+                       |  (in PTY mode)  |
|             +----------------------->                 |
| Application |                       |                 |
|             <-----------------------+                 |
+-------------+                       |                 |
                 mouse information    |                 |
                 1002 in 1005 format  |                 |
                                      |                 |
                                      +---+---------^---+
                                          |         |
                                          |         | mouse information in
                         DECSET 1002,1006 |         | SGR Extended Format
                                          |         | (1002+1006)
                                          |         |
                                      +---v---------+---+
                                      |                 |
                                      | Windows         |
                                      |  Terminal       |
                                      |                 |
                                      |                 |
                                      |                 |
                                      |                 |
                                      +-----------------+

@egmontkob
Copy link

Did you mean 1005 between the application and conhost, or is that a typo in this picture? Mouse extensions 1005 and 1015 also exist but they are hardly used (if at all) due to their flaws, it's not something that applications are interested in.

1005 (xterm's two-byte UTF-8), 1015 (urxvt) and 1006 (xterm SGR), in this chronological order, are three mutually exclusive extensions to address the limitation of the column number. See e.g. Midnight Commander issues 2662 and 2956 for technical description about the flaws of the first two. Note that this story is now 6-8 years old. I'm not aware of any application that supports the problematic 1005 and/or 1015 but not the okay 1006. As such, I don't see any point in implementing support for the first two (although it should be very easy to implement them).

@zadjii-msft
Copy link
Member

That very well could be a typo, right now, conhost actually supports a bunch of different mouse modes, including, but not limited to 1005 and 1006.

DHowett-MSFT pushed a commit that referenced this issue Mar 13, 2020
## Summary of the Pull Request
Make TerminalControl synthesize mouse events and Terminal send them to
the TerminalInput's MouseInput module.

The implementation here takes significant inspiration from how we handle
KeyEvents.

## References
Closes #545 - VT Mouse Mode (Terminal)
References #376 - VT Mouse Mode (ConPty)

### TerminalControl
- `_TrySendMouseEvent` attempts to send a mouse event via TermInput.
  Similar to `_TrySendKeyEvent`
- Use the above function to try and send the mouse event _before_
  deciding to modify the selection

### TerminalApi
- Hookup (re)setting the various modes to handle VT Input
- Terminal is _always_ in VT Input mode (important for #4856)

### TerminalDispatch
- Hookup (re)setting the various modes to handle VT Input

### TerminalInput
- Convert the mouse input position from viewport position to buffer
  position
- Then send it over to the MouseInput in TerminalInput to actually do it
  (#4848)

## Validation Steps Performed
Tests should still pass.
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Mar 13, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Mar 13, 2020
@giggio
Copy link

giggio commented Mar 17, 2020

How do we copy the text when VT Mouse is enabled? I couldn't do it on Vim or Tmux.

@DHowett-MSFT
Copy link
Contributor

Hold down shift to interact with the terminal itself instead of the application inside it.

@PetterS
Copy link

PetterS commented Mar 17, 2020

This is so great! When will we see a preview of this in the Store?

@DHowett-MSFT
Copy link
Contributor

Stay tuned

@yveslange
Copy link

yveslange commented Mar 18, 2020

Downloaded from the shop! The mouse is working great in VIM, htop and Tmux. Finally, time to move from all other WSL Terminal to the microsoft one ! Good job guys and thanks a lot !

PS: shift is working great too !

@jsbarrett
Copy link

Just came here looking for why mouse wasn't working ... read the most recent comment from @yveslange and then updated the app ... and now mouse works perfect.

Thanks guys!

@nicolus
Copy link

nicolus commented Mar 29, 2020

@DHowett-MSFT : Mouse still doesn't work for me with Micro (https://github.com/zyedidia/micro), whereas both mouse and scrollwheel work flawlessly in the default powershell or cmd.exe terminal. Is mouse support only working in WSL for now ?

@zadjii-msft
Copy link
Member

@nicolus indeed, mouse input only works for WSL applications currently. If you're using the Win32 version of micro, I'd bet that it won't work quite yet. You could probably work around this by running the WSL version for now. #376 is the issue we're using for the Windows mouse input

@CodeMonkey90
Copy link

CodeMonkey90 commented May 11, 2020

@zadjii-msft
Mouse events don't work for me with a custom profile with "commandline": "ssh [...]". Is this also expected until #376 is resolved? Is there a good workaround?

Edit: Or is that just a result of PowerShell/Win32-OpenSSH#1310 and would work otherwise?

@DHowett-MSFT
Copy link
Contributor

This is a result of PowerShell/Win32-OpenSSH#1310, which is (mercifully) fixed in the 8.x series.

@CodeMonkey90
Copy link

@DHowett-MSFT Thanks for the quick reply. In that case, is there a sane way to manually upgrade to a version with the fix right now or is it better to just wait?

@DHowett-MSFT
Copy link
Contributor

Sure, just download the latest release from their Releases page!

@rfc805
Copy link

rfc805 commented Aug 9, 2021

I don't see it here or in the documentation, but how do you turn this behavior off entirely? It's incredibly annoying for people who don't want to have mouse interactions pass through. Holding shift is not a good option.

@zadjii-msft
Copy link
Member

@rfc805 there isn't a setting to disable this entirely - I'm not sure I've heard anyone request that before. Typically this is something that's controlled per-client application on other platforms, within the app's own config. Is there some app (vim, tmux, etc) in particular that's requesting mouse mode that you can't disable mouse input for?

@rfc805
Copy link

rfc805 commented Aug 9, 2021

It's mostly vim (over ssh) but on a large variety of hosts which aren't related, which makes it non-trivial to globally disable in unlinked/unshared profiles across a few hundred different remote hosts. A lot of it involves copying data from those hosts across each other, or to other Windows apps, etc - so I find myself holding shift down my whole life if I use terminal instead of putty/mintty.

@zadjii-msft
Copy link
Member

You know, this actually already is on the backlog. I'd go upvote #4875 ☺️

@paukul
Copy link

paukul commented Aug 9, 2021

@rfc805 :set mouse-=a in vim will disable the mouse support for vim and should work around your issue until #4875 is merged

@rfc805
Copy link

rfc805 commented Aug 9, 2021

Thanks - I do know how to do it each time, just overall a productivity killer if you work in a large environment with a profile you do not control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.