starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Mouse Input only partially working in WSL #17556

New Issue
Closed
opened 2026-01-31 05:45:51 +00:00 by claunia · 15 comments
claunia commented 2026-01-31 05:45:51 +00:00
Owner
Copy Link

Originally created by @RoiEXLab on GitHub (May 25, 2022).

Windows Terminal version

1.12.10982.0

Windows build number

10.0.19044.1645

Other Software

ncurses (inside WSL)

Steps to reproduce

I originally reported this to https://github.com/microsoft/WSL/issues/8439 where I was told I should actually report it here.

  1. Clone and build the example project provided by imtui. Any other application that uses ncurses should work too but this project is easy to work with.
  2. Try to drag one of the windows to the far right of the terminal or hover over the right side of the terminal with the mouse cursor

Expected Behavior

I would expect the mouse to continue working regardless of the X or Y coordinate of the terminal

Actual Behavior

You will notice that at a certain coordinate (94 in the X or Y direction is the last working cell for me) the drag suddenly stops even though the mouse travels further to the right.
The same can be observed when using the default wsl window (I assume that's conhost.exe?), without Windows Terminal.

This issue does not happen when using the internal terminal provided by VS Code (in WSL mode, outside of WSL it is even worse than outside of VS Code), nor does it happen when using a Linux terminal within a regular VM

Originally created by @RoiEXLab on GitHub (May 25, 2022). ### Windows Terminal version 1.12.10982.0 ### Windows build number 10.0.19044.1645 ### Other Software ncurses (inside WSL) ### Steps to reproduce I originally reported this to https://github.com/microsoft/WSL/issues/8439 where I was told I should actually report it here. 1. Clone and build the example project provided by [imtui](https://github.com/ggerganov/imtui). Any other application that uses ncurses should work too but this project is easy to work with. 2. Try to drag one of the windows to the far right of the terminal or hover over the right side of the terminal with the mouse cursor ### Expected Behavior I would expect the mouse to continue working regardless of the X or Y coordinate of the terminal ### Actual Behavior You will notice that at a certain coordinate (94 in the X or Y direction is the last working cell for me) the drag suddenly stops even though the mouse travels further to the right. The same can be observed when using the default wsl window (I assume that's `conhost.exe`?), without Windows Terminal. This issue does not happen when using the internal terminal provided by VS Code (in WSL mode, outside of WSL it is even worse than outside of VS Code), nor does it happen when using a Linux terminal within a regular VM
claunia added the Issue-BugResolution-Duplicate labels 2026-01-31 05:45:51 +00:00
claunia commented 2026-01-31 05:45:52 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (May 25, 2022):

@RoiEXLab your test seems to work with terminal 1.14.1432.0 and Windows 10.0.19044:

https://user-images.githubusercontent.com/3933920/170173841-2f7dcf22-0171-4c62-be41-4641d595a220.mp4

@elsaco commented on GitHub (May 25, 2022): @RoiEXLab your test seems to work with terminal 1.14.1432.0 and Windows 10.0.19044: https://user-images.githubusercontent.com/3933920/170173841-2f7dcf22-0171-4c62-be41-4641d595a220.mp4
claunia commented 2026-01-31 05:45:52 +00:00
Author
Owner
Copy Link

@RoiEXLab commented on GitHub (May 25, 2022):

@elsaco I Downloaded the latest "Windows Terminal Preview" (Version 1.14.143 according to the Windows Store Page) and the issue continues to persist for me. In the small "debug window" in this example project the mouse x and y coordinate just doesn't increase above 94.

The issue does also happen outside of Windows Terminal, so maybe there is some kind of deeper configuration issue there?

My conhost.exe Version is 10.0.19041.1566. This is how I set the preferences (windows is in german, sorry about that):
Screenshot 1
Screenshot 2
Screenshot 3
Screenshot 4
Screenshot 5

Please tell me if there's some additional Info I can provide

@RoiEXLab commented on GitHub (May 25, 2022): @elsaco I Downloaded the latest "Windows Terminal Preview" (Version 1.14.143 according to the Windows Store Page) and the issue continues to persist for me. In the small "debug window" in this example project the mouse x and y coordinate just doesn't increase above 94. The issue does also happen outside of Windows Terminal, so maybe there is some kind of deeper configuration issue there? My `conhost.exe` Version is `10.0.19041.1566`. This is how I set the preferences (windows is in german, sorry about that): ![Screenshot 1](https://user-images.githubusercontent.com/8350879/170197399-264687f8-3f84-47fe-810e-5ee94d344ab8.png) ![Screenshot 2](https://user-images.githubusercontent.com/8350879/170197630-2dea20d9-c914-4875-a17d-65fd59deef83.png) ![Screenshot 3](https://user-images.githubusercontent.com/8350879/170197708-adc1b0da-23f5-4828-a704-1c34ed64872e.png) ![Screenshot 4](https://user-images.githubusercontent.com/8350879/170197746-42444a1a-c5ca-4640-a378-90eb87842a0a.png) ![Screenshot 5](https://user-images.githubusercontent.com/8350879/170197774-255c6827-85a0-4149-b3d3-9474659de321.png) Please tell me if there's some additional Info I can provide
claunia commented 2026-01-31 05:45:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 25, 2022):

So, this is basically the same root cause as #9928. The original VT mouse encoding[1] doesn't work past column ~93, due to some encoding issues. SGR mouse encoding, however, has no such issues. I'd reckon that imtui needs to be updated to use that encoding instead.

[1]: That doc mentions 223, but there's some issues that exist between the console and WSL.exe that cause us to be limited to only 93. Alas. More details in https://github.com/microsoft/terminal/issues/5454#issuecomment-656250431

/dup #9928

@zadjii-msft commented on GitHub (May 25, 2022): So, this is basically the same root cause as #9928. The [original VT mouse encoding](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Extended-coordinates)[1] doesn't work past column ~93, due to some encoding issues. SGR mouse encoding, however, has no such issues. I'd reckon that imtui needs to be updated to use that encoding instead. [1]: That doc mentions 223, but there's some issues that exist between the console and WSL.exe that cause us to be limited to only 93. Alas. More details in https://github.com/microsoft/terminal/issues/5454#issuecomment-656250431 /dup #9928
claunia commented 2026-01-31 05:45:52 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 25, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (May 25, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 05:45:53 +00:00
Author
Owner
Copy Link

@RoiEXLab commented on GitHub (May 25, 2022):

@zadjii-msft Thanks for your reply. This makes a ton of sense, but some points remain unclear to me:
How come that this issue doesn't occur to @elsaco ?
Also when is the type of the mouse encoding set? Does the application request a certain encoding, or does it just have to interpret a given encoding correctly? Does the shell have something to do with it?

I'd appreciate if you could help me understand this issue better.

@RoiEXLab commented on GitHub (May 25, 2022): @zadjii-msft Thanks for your reply. This makes a ton of sense, but some points remain unclear to me: How come that this issue doesn't occur to @elsaco ? Also when is the type of the mouse encoding set? Does the application request a certain encoding, or does it just have to interpret a given encoding correctly? Does the shell have something to do with it? I'd appreciate if you could help me understand this issue better.
claunia commented 2026-01-31 05:45:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 25, 2022):

That's.... a good question. Maybe it's a imtui version difference?

Mouse encodings are requested by the client application (in this case, imtui-example-ncurses0). The application has to say "I would like to receive mouse input, and I would like it in this format please". I would be shocked if the shell had anything to do with this. There's a chance that internally, the library is trying to do something different for Windows vs Linux. But that would affect things far more than just the encoding of mouse sequences.

The fact that you note that it's specifically column 94 is what makes me think that this is the VT mouse mode encoding issue. That's such a specific number, I'd be stunned to find it caused by something else.

@zadjii-msft commented on GitHub (May 25, 2022): That's.... a good question. Maybe it's a imtui version difference? Mouse encodings are requested by the client application (in this case, `imtui-example-ncurses0`). The application has to say "I would like to receive mouse input, and I would like it in this format please". I would be shocked if the shell had anything to do with this. There's a chance that internally, the library is trying to do something different for Windows vs Linux. But that would affect things far more than just the encoding of mouse sequences. The fact that you note that it's specifically column 94 is what makes me think that this is the VT mouse mode encoding issue. That's such a specific number, I'd be stunned to find it caused by something else.
claunia commented 2026-01-31 05:45:53 +00:00
Author
Owner
Copy Link

@RoiEXLab commented on GitHub (May 25, 2022):

@zadjii-msft

That's.... a good question. Maybe it's a imtui version difference?

I don't think so, maybe there's a difference with the ncurses headers provided by ubuntu. I'm on 20.04.

Regardless I want to make clear I don't use imtui at all, it's just a convenient project that I was using to reproduce the error. In reality I'm just concerned about ncurses handling of this. Ncurses is supposed to support the 1006 extension as of version 6.1, but the documentation on how this support is supposed to look like is very sparse. I was able to find out that setting the environment variable TERM=xterm-1006 does serve as an okay-ish workaround for my particular use-case (which is used for teaching C++ beginners the basics without having to learn OpenGL or some other UI framework), but it drops the support for coloured terminals, which is a shame but not a deal-breaker.

But I'd really like to find out how I can get ncurses to request the 1006 encoding without me having to set the environment variable.

@RoiEXLab commented on GitHub (May 25, 2022): @zadjii-msft > That's.... a good question. Maybe it's a imtui version difference? I don't think so, maybe there's a difference with the ncurses headers provided by ubuntu. I'm on 20.04. Regardless I want to make clear I don't use imtui at all, it's just a convenient project that I was using to reproduce the error. In reality I'm just concerned about ncurses handling of this. Ncurses is supposed to support the 1006 extension as of version 6.1, but the documentation on how this support is supposed to look like is very sparse. I was able to find out that setting the environment variable `TERM=xterm-1006` does serve as an okay-ish workaround for my particular use-case (which is used for teaching C++ beginners the basics without having to learn OpenGL or some other UI framework), but it drops the support for coloured terminals, which is a shame but not a deal-breaker. But I'd really like to find out how I can get ncurses to request the 1006 encoding without me having to set the environment variable.
claunia commented 2026-01-31 05:45:53 +00:00
Author
Owner
Copy Link

@Sir-Will commented on GitHub (May 25, 2022):

I'm experiencing the issue where click inputs are not working at a specific width.
To reproduce the issue I ssh into an ubuntu server, run htop and click on a process to the far right.

Is this the same issue as described here?

With macOS and iTerm2 I'm unable to reproduce the issue.

@Sir-Will commented on GitHub (May 25, 2022): I'm experiencing the issue where click inputs are not working at a specific width. To reproduce the issue I ssh into an ubuntu server, run `htop` and click on a process to the far right. Is this the same issue as described here? With macOS and iTerm2 I'm unable to reproduce the issue.
claunia commented 2026-01-31 05:45:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 25, 2022):

I'm experiencing the issue where click inputs are not working at a specific width.

To reproduce the issue I ssh into an ubuntu server, run htop and click on a process to the far right.

Is this the same issue as described here?

With macOS and iTerm2 I'm unable to reproduce the issue.

If the column at which it stops working is 94, then you have this issue and the remediation is the same 😃

@DHowett commented on GitHub (May 25, 2022): > I'm experiencing the issue where click inputs are not working at a specific width. > > To reproduce the issue I ssh into an ubuntu server, run `htop` and click on a process to the far right. > > > > Is this the same issue as described here? > > > > With macOS and iTerm2 I'm unable to reproduce the issue. If the column at which it stops working is 94, then you have this issue and the remediation is the same 😃
claunia commented 2026-01-31 05:45:54 +00:00
Author
Owner
Copy Link

@Sir-Will commented on GitHub (May 25, 2022):

Yea, seems to stop working at 94.

@Sir-Will commented on GitHub (May 25, 2022): Yea, seems to stop working at 94.
claunia commented 2026-01-31 05:45:54 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (May 26, 2022):

@RoiEXLab your conhost window size is set to 80x25. On my system it matches the the terminal size (default 120x30):

conhost_windows_size

If you increase the window size, does it makes any difference? Thx!

@elsaco commented on GitHub (May 26, 2022): @RoiEXLab your `conhost` window size is set to 80x25. On my system it matches the the terminal size (default 120x30): ![conhost_windows_size](https://user-images.githubusercontent.com/3933920/170384516-249eaa46-1101-4b7b-b436-40e4f39d4c9c.png) If you increase the window size, does it makes any difference? Thx!
claunia commented 2026-01-31 05:45:54 +00:00
Author
Owner
Copy Link

@RoiEXLab commented on GitHub (May 26, 2022):

@elsaco On my Desktop (where the issue also occurs) it uses the 120x30 size by default. I guess that's just a thing on my Laptop because it uses 125% zoom due to the small screen or something. So no, it doesn't make a difference.

However I did read some documentation in the meantime and learned a couple of things about terminals and ncurses on linux.
It seems that the XM capability has something to do with this issue.

@elsaco Would you be so kind to post the console output of

infocmp -x "$TERM"

On your machine where the issue doesn't occur? My current $TERM is set to xterm-256color which does not have a value for XM, which is mentioned in the documentation for ncurses and used in the source code:
a0c6d9cb65/ncurses/base/lib_mouse.c (L391-L438)

When running

infocmp -x xterm-256color xterm-1006

on my machine to display the differences between the terminal configurations I get this output:

comparing xterm-256color to xterm-1006.
    comparing booleans.
        ccc: T:F.
    comparing numbers.
        colors: 256, 8.
        pairs: 65536, 64.
    comparing strings.
        initc: '\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\', NULL.
        ka1: NULL, '\EOw'.
        ka3: NULL, '\EOy'.
        kb2: '\EOE', '\EOu'.
        kc1: NULL, '\EOq'.
        kc3: NULL, '\EOs'.
        kmous: '\E[M', '\E[<'.
        mgc: NULL, '\E[?69l'.
        oc: '\E]104\007', NULL.
        rep: NULL, '%p1%c\E[%p2%{1}%-%db'.
        rs1: '\Ec\E]104\007', '\Ec'.
        setab: '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m', '\E[4%p1%dm'.
        setaf: '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m', '\E[3%p1%dm'.
        setb: NULL, '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m'.
        setf: NULL, '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m'.
        smglr: NULL, '\E[?69h\E[%i%p1%d;%p2%ds'.
        XM: NULL, '\E[?1006;1000%?%p1%{1}%=%th%el%;'.
        ka2: NULL, '\EOx'.
        kb1: NULL, '\EOt'.
        kb3: NULL, '\EOv'.
        kc2: NULL, '\EOr'.
        kp5: NULL, '\EOE'.
        kpADD: NULL, '\EOk'.
        kpCMA: NULL, '\EOl'.
        kpDIV: NULL, '\EOo'.
        kpDOT: NULL, '\EOn'.
        kpMUL: NULL, '\EOj'.
        kpSUB: NULL, '\EOm'.
        kpZRO: NULL, '\EOp'.
        xm: NULL, '\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;'.

As you can seen the XM string is present. I tried to modify my existing xterm-256color terminal configuration (no idea how this is actually called) as explained in this stackoverflow post to include this XM string. While it did actually alter behaviour it became worse, suddenly no mouse input worked anymore. I assume I need to include more of those keys to make it work, but I haven't gotten to try it yet, so I just reverted my changes to the buggy version I had before.

@RoiEXLab commented on GitHub (May 26, 2022): @elsaco On my Desktop (where the issue also occurs) it uses the 120x30 size by default. I guess that's just a thing on my Laptop because it uses 125% zoom due to the small screen or something. So no, it doesn't make a difference. However I did read some documentation in the meantime and learned a couple of things about terminals and ncurses on linux. It seems that the `XM` capability has something to do with this issue. @elsaco Would you be so kind to post the console output of ```bash infocmp -x "$TERM" ``` On your machine where the issue doesn't occur? My current `$TERM` is set to `xterm-256color` which does not have a value for `XM`, which is mentioned in the [documentation for ncurses](https://man7.org/linux/man-pages/man5/user_caps.5.html) and used in the source code: https://github.com/mirror/ncurses/blob/a0c6d9cb65b77a62ca49e88f6b49e2e5f052407f/ncurses/base/lib_mouse.c#L391-L438 When running ```bash infocmp -x xterm-256color xterm-1006 ``` on my machine to display the differences between the terminal configurations I get this output: ``` comparing xterm-256color to xterm-1006. comparing booleans. ccc: T:F. comparing numbers. colors: 256, 8. pairs: 65536, 64. comparing strings. initc: '\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\', NULL. ka1: NULL, '\EOw'. ka3: NULL, '\EOy'. kb2: '\EOE', '\EOu'. kc1: NULL, '\EOq'. kc3: NULL, '\EOs'. kmous: '\E[M', '\E[<'. mgc: NULL, '\E[?69l'. oc: '\E]104\007', NULL. rep: NULL, '%p1%c\E[%p2%{1}%-%db'. rs1: '\Ec\E]104\007', '\Ec'. setab: '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m', '\E[4%p1%dm'. setaf: '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m', '\E[3%p1%dm'. setb: NULL, '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m'. setf: NULL, '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m'. smglr: NULL, '\E[?69h\E[%i%p1%d;%p2%ds'. XM: NULL, '\E[?1006;1000%?%p1%{1}%=%th%el%;'. ka2: NULL, '\EOx'. kb1: NULL, '\EOt'. kb3: NULL, '\EOv'. kc2: NULL, '\EOr'. kp5: NULL, '\EOE'. kpADD: NULL, '\EOk'. kpCMA: NULL, '\EOl'. kpDIV: NULL, '\EOo'. kpDOT: NULL, '\EOn'. kpMUL: NULL, '\EOj'. kpSUB: NULL, '\EOm'. kpZRO: NULL, '\EOp'. xm: NULL, '\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;'. ``` As you can seen the `XM` string is present. I tried to modify my existing `xterm-256color` terminal configuration (no idea how this is actually called) as explained in [this stackoverflow post](https://stackoverflow.com/a/29023361/5769952) to include this `XM` string. While it did actually alter behaviour it became worse, suddenly no mouse input worked anymore. I assume I need to include more of those keys to make it work, but I haven't gotten to try it yet, so I just reverted my changes to the buggy version I had before.
claunia commented 2026-01-31 05:45:55 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (May 26, 2022):

I played with imtui more and this is what was observed. Using Ubuntu 22.04 it works as expected. The previous video was taken on a Windows 10 workstation. This was taken at home on Windows 11 with latest terminal preview:

https://user-images.githubusercontent.com/3933920/170404093-5bddb489-9bfa-4310-b1b6-e41ba5d83299.mp4

There's a new option available called passthrough. It needs to be set in settings.json for now. When enabled on the same WSL instance it doesn't work at all. Notice there are some escape codes being displayed at bottom left corner and nothing can be moved around:

https://user-images.githubusercontent.com/3933920/170404501-8eae0578-a1aa-4dc9-a1a9-b7c36231e1c7.mp4

When using the Ubuntu 20.04 instance the bug is present. The selection can't be dragged past x=94:

https://user-images.githubusercontent.com/3933920/170404774-89e38866-d5e9-4288-8c48-8ff0ccc7b89b.mp4

Both test were done on WSL:

PS C:\Users\elsaco> wsl --status
Default Distribution: fedoraremix
Default Version: 2
WSL version: 0.58.3.0
Kernel version: 5.10.102.1
WSLg version: 1.0.33
MSRDC version: 1.2.2924
Direct3D version: 1.601.0
Windows version: 10.0.22000.708

On both Ubuntu instances the libncurses is the same version, when running ldd -v imtui-example-ncurses0 it shows:

libncurses.so.6 (NCURSES6_5.7.20081102) => /lib/x86_64-linux-gnu/libncurses.so.6
libncurses.so.6 (NCURSES6_5.0.19991023) => /lib/x86_64-linux-gnu/libncurses.so.6
@elsaco commented on GitHub (May 26, 2022): I played with `imtui` more and this is what was observed. Using Ubuntu 22.04 it works as expected. The previous video was taken on a Windows 10 workstation. This was taken at home on Windows 11 with latest `terminal preview`: https://user-images.githubusercontent.com/3933920/170404093-5bddb489-9bfa-4310-b1b6-e41ba5d83299.mp4 There's a new option available called `passthrough`. It needs to be set in `settings.json` for now. When enabled on the same WSL instance it doesn't work at all. Notice there are some escape codes being displayed at bottom left corner and nothing can be moved around: https://user-images.githubusercontent.com/3933920/170404501-8eae0578-a1aa-4dc9-a1a9-b7c36231e1c7.mp4 When using the Ubuntu 20.04 instance the bug is present. The selection can't be dragged past `x=94`: https://user-images.githubusercontent.com/3933920/170404774-89e38866-d5e9-4288-8c48-8ff0ccc7b89b.mp4 Both test were done on WSL: ``` PS C:\Users\elsaco> wsl --status Default Distribution: fedoraremix Default Version: 2 WSL version: 0.58.3.0 Kernel version: 5.10.102.1 WSLg version: 1.0.33 MSRDC version: 1.2.2924 Direct3D version: 1.601.0 Windows version: 10.0.22000.708 ``` On both Ubuntu instances the `libncurses` is the same version, when running `ldd -v imtui-example-ncurses0` it shows: ``` libncurses.so.6 (NCURSES6_5.7.20081102) => /lib/x86_64-linux-gnu/libncurses.so.6 libncurses.so.6 (NCURSES6_5.0.19991023) => /lib/x86_64-linux-gnu/libncurses.so.6 ```
claunia commented 2026-01-31 05:45:55 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (May 26, 2022):

Both terminals are xterm-256color and this is the difference in infocmp output:

tux@eleven:~/foo$ diff jammy  focal
16c16
<         initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
---
>         initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
19,20c19
<         kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw,
<         ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,
---
>         kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?,
40c39
<         kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
---
>         kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
42,44c41,42
<         memu=\Em, mgc=\E[?69l, nel=\EE, oc=\E]104\007,
<         op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db,
<         rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
---
>         memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8, rev=\E[7m,
>         ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
52,54c50
<         smcup=\E[?1049h\E[22;0;0t, smglp=\E[?69h\E[%i%p1%ds,
<         smglr=\E[?69h\E[%i%p1%d;%p2%ds,
<         smgrp=\E[?69h\E[%i;%p1%ds, smir=\E[4h, smkx=\E[?1h\E=,
---
>         smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
59,63c55,58
<         Se=\E[2 q, Ss=\E[%p1%d q,
<         XM=\E[?1006;1000%?%p1%{1}%=%th%el%;, kDC3=\E[3;3~,
<         kDC4=\E[3;4~, kDC5=\E[3;5~, kDC6=\E[3;6~, kDC7=\E[3;7~,
<         kDN=\E[1;2B, kDN3=\E[1;3B, kDN4=\E[1;4B, kDN5=\E[1;5B,
<         kDN6=\E[1;6B, kDN7=\E[1;7B, kEND3=\E[1;3F, kEND4=\E[1;4F,
---
>         Se=\E[2 q, Ss=\E[%p1%d q, kDC3=\E[3;3~, kDC4=\E[3;4~,
>         kDC5=\E[3;5~, kDC6=\E[3;6~, kDC7=\E[3;7~, kDN=\E[1;2B,
>         kDN3=\E[1;3B, kDN4=\E[1;4B, kDN5=\E[1;5B, kDN6=\E[1;6B,
>         kDN7=\E[1;7B, kEND3=\E[1;3F, kEND4=\E[1;4F,
75,79c70,71
<         kUP5=\E[1;5A, kUP6=\E[1;6A, kUP7=\E[1;7A, ka2=\EOx,
<         kb1=\EOt, kb3=\EOv, kc2=\EOr, kp5=\EOE, kpADD=\EOk,
<         kpCMA=\EOl, kpDIV=\EOo, kpDOT=\EOn, kpMUL=\EOj, kpSUB=\EOm,
<         kpZRO=\EOp, rmxx=\E[29m, smxx=\E[9m,
<         xm=\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;,
---
>         kUP5=\E[1;5A, kUP6=\E[1;6A, kUP7=\E[1;7A, rmxx=\E[29m,
>         smxx=\E[9m,
@elsaco commented on GitHub (May 26, 2022): Both terminals are `xterm-256color` and this is the difference in `infocmp` output: ``` tux@eleven:~/foo$ diff jammy focal 16c16 < initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, --- > initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, 19,20c19 < kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw, < ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs, --- > kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?, 40c39 < kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~, --- > kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~, 42,44c41,42 < memu=\Em, mgc=\E[?69l, nel=\EE, oc=\E]104\007, < op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db, < rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, --- > memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8, rev=\E[7m, > ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, 52,54c50 < smcup=\E[?1049h\E[22;0;0t, smglp=\E[?69h\E[%i%p1%ds, < smglr=\E[?69h\E[%i%p1%d;%p2%ds, < smgrp=\E[?69h\E[%i;%p1%ds, smir=\E[4h, smkx=\E[?1h\E=, --- > smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=, 59,63c55,58 < Se=\E[2 q, Ss=\E[%p1%d q, < XM=\E[?1006;1000%?%p1%{1}%=%th%el%;, kDC3=\E[3;3~, < kDC4=\E[3;4~, kDC5=\E[3;5~, kDC6=\E[3;6~, kDC7=\E[3;7~, < kDN=\E[1;2B, kDN3=\E[1;3B, kDN4=\E[1;4B, kDN5=\E[1;5B, < kDN6=\E[1;6B, kDN7=\E[1;7B, kEND3=\E[1;3F, kEND4=\E[1;4F, --- > Se=\E[2 q, Ss=\E[%p1%d q, kDC3=\E[3;3~, kDC4=\E[3;4~, > kDC5=\E[3;5~, kDC6=\E[3;6~, kDC7=\E[3;7~, kDN=\E[1;2B, > kDN3=\E[1;3B, kDN4=\E[1;4B, kDN5=\E[1;5B, kDN6=\E[1;6B, > kDN7=\E[1;7B, kEND3=\E[1;3F, kEND4=\E[1;4F, 75,79c70,71 < kUP5=\E[1;5A, kUP6=\E[1;6A, kUP7=\E[1;7A, ka2=\EOx, < kb1=\EOt, kb3=\EOv, kc2=\EOr, kp5=\EOE, kpADD=\EOk, < kpCMA=\EOl, kpDIV=\EOo, kpDOT=\EOn, kpMUL=\EOj, kpSUB=\EOm, < kpZRO=\EOp, rmxx=\E[29m, smxx=\E[9m, < xm=\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;, --- > kUP5=\E[1;5A, kUP6=\E[1;6A, kUP7=\E[1;7A, rmxx=\E[29m, > smxx=\E[9m, ```
claunia commented 2026-01-31 05:45:56 +00:00
Author
Owner
Copy Link

@RoiEXLab commented on GitHub (May 26, 2022):

@elsaco Thanks for your information.
I was able to fix this issue on Ubuntu 20.04 by simply copying the terminfo from Ubuntu 22.04 and it works like a charm. No changes to the binary required. So I would consider this a better solution to the problem, or simply updating to Ubuntu 22.04 if that's a possibility.

@RoiEXLab commented on GitHub (May 26, 2022): @elsaco Thanks for your information. I was able to fix this issue on Ubuntu 20.04 by simply copying the terminfo from Ubuntu 22.04 and it works like a charm. No changes to the binary required. So I would consider this a better solution to the problem, or simply updating to Ubuntu 22.04 if that's a possibility.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17556
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?