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

mouse events are sent incorrectly in win32-input-mode #19617

New Issue
Open
opened 2026-01-31 06:48:48 +00:00 by claunia · 21 comments
claunia commented 2026-01-31 06:48:48 +00:00
Owner
Copy Link

Originally created by @unxed on GitHub (Apr 2, 2023).

Steps to reproduce

  1. Compile this test app using gcc under WSL:
#include <termios.h> 
#include <assert.h>
#include <errno.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 


int main()
{
    struct termios _ts = {};
	int _ts_r = tcgetattr(1, &_ts);
	if (_ts_r == 0) {
		struct termios ts_ne = _ts;
		//ts_ne.c_lflag &= ~(ECHO | ECHONL);
		cfmakeraw(&ts_ne);
		if (tcsetattr(1, TCSADRAIN, &ts_ne ) != 0) {
			perror("TTYBackend: tcsetattr");
		}
	}

	fprintf(stderr, "\x1b[?1049h");
	fprintf(stderr, "\x1b[?1000h");
	fprintf(stderr, "\x1b[?1001h");
	fprintf(stderr, "\x1b[?1002h");

	fprintf(stderr, "\x1b[?9001h");

	for (;;) {
		char ch = 0;
		if (read(0, &ch, 1) <= 0) break;
		if (ch <= 0x20 || ch == 0x7f) {
			if (ch == 0x1b) fprintf(stderr, " ");
			fprintf(stderr, "\\x%02x", (unsigned int)(unsigned char)ch);
		} else {
			fprintf(stderr, "%c", ch);
		}
		if (ch == 0x0d) break;
    	if (ch == 0x0a) break;
	}
	fprintf(stderr, "\x1b[?1049l");
	fprintf(stderr, "\x1b[?1000l");
	fprintf(stderr, "\x1b[?1001l");
	fprintf(stderr, "\x1b[?1002l");

	fprintf(stderr, "\x1b[?9001l");

	if (tcsetattr(1, TCSADRAIN, &_ts ) != 0) {
		perror("TTYBackend: tcsetattr");
	}
}

  1. Run it under Windows Terminal

  2. Move mouse over the terminal window.

Expected Behavior

We should see mouse movement escape sequences (\x1b[M... format)

Actual Behavior

We see win32-input-mode escape sequences (\x1b[A;B;C;D;E;F_ format)

изображение

Originally created by @unxed on GitHub (Apr 2, 2023). ### Steps to reproduce 1. Compile this test app using gcc under WSL: ``` #include <termios.h> #include <assert.h> #include <errno.h> #include <signal.h> #include <fcntl.h> #include <sys/ioctl.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> int main() { struct termios _ts = {}; int _ts_r = tcgetattr(1, &_ts); if (_ts_r == 0) { struct termios ts_ne = _ts; //ts_ne.c_lflag &= ~(ECHO | ECHONL); cfmakeraw(&ts_ne); if (tcsetattr(1, TCSADRAIN, &ts_ne ) != 0) { perror("TTYBackend: tcsetattr"); } } fprintf(stderr, "\x1b[?1049h"); fprintf(stderr, "\x1b[?1000h"); fprintf(stderr, "\x1b[?1001h"); fprintf(stderr, "\x1b[?1002h"); fprintf(stderr, "\x1b[?9001h"); for (;;) { char ch = 0; if (read(0, &ch, 1) <= 0) break; if (ch <= 0x20 || ch == 0x7f) { if (ch == 0x1b) fprintf(stderr, " "); fprintf(stderr, "\\x%02x", (unsigned int)(unsigned char)ch); } else { fprintf(stderr, "%c", ch); } if (ch == 0x0d) break; if (ch == 0x0a) break; } fprintf(stderr, "\x1b[?1049l"); fprintf(stderr, "\x1b[?1000l"); fprintf(stderr, "\x1b[?1001l"); fprintf(stderr, "\x1b[?1002l"); fprintf(stderr, "\x1b[?9001l"); if (tcsetattr(1, TCSADRAIN, &_ts ) != 0) { perror("TTYBackend: tcsetattr"); } } ``` 2. Run it under Windows Terminal 3. Move mouse over the terminal window. ### Expected Behavior We should see mouse movement escape sequences (`\x1b[M...` format) ### Actual Behavior We see win32-input-mode escape sequences (`\x1b[A;B;C;D;E;F_` format) ![изображение](https://user-images.githubusercontent.com/1151423/229324322-11b546ed-8f84-40d1-8e13-a1930edef110.png)
claunia commented 2026-01-31 06:48:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 6, 2023):

This is very much probably a corner case we never expected. We didn't actually vet win32 input mode for compatibility with applications (!) as it was originally a stopgap for getting our two terminal emulators to agree on how to handle key events.

This explanation is going to use some terms specific to this codebase.

When we generate a mouse event, we serialize it into a set of key events in InputStateMachineEngine for maximal compatibility with Win32 console applications (which are expecting a Windows API called ReadConsoleInput to return events rather than a string).

It seems we're taking those key events re-encoding them as win32 input events again. From one capture, I see this:

\x1b[0;0;27;1;0;1_   -> \x1b  (pressed)
\x1b[0;0;91;1;0;1_   -> [     (pressed)
\x1b[0;0;77;1;0;1_   -> M     (pressed)
\x1b[56;9;56;1;0;1_  -> 8     (pressed)
\x1b[56;9;56;0;0;1_  -> 8     (released)
\x1b[0;0;27;1;0;1_   -> \x1b  (pressed)
\x1b[0;0;91;1;0;1_   -> [     (pressed)
\x1b[0;0;77;1;0;1_   -> M     (pressed)
\x1b[16;42;0;1;16;1_ -> ???   (pressed)
\x1b[51;4;35;1;16;1_ -> #     (pressed)
\x1b[51;4;35;0;16;1_ -> #     (released)
\x1b[16;42;0;0;0;1_  -> ???   (released)

Which is, of course, entirely bogus.

You're also going to see this for any DSR-CPR, any X11 focus mode, and any other types of answerback.

Excellent find!

@DHowett commented on GitHub (Apr 6, 2023): This is very much probably a corner case we never expected. We didn't actually vet win32 input mode for compatibility with applications (!) as it was originally a stopgap for getting our two terminal emulators to agree on how to handle key events. This explanation is going to use some terms specific to this codebase. When we generate a mouse event, we serialize it into a set of key events in `InputStateMachineEngine` for maximal compatibility with Win32 console applications (which are expecting a Windows API called `ReadConsoleInput` to return events rather than a string). It *seems* we're taking those key events _re-encoding them_ as win32 input events again. From one capture, I see this: ``` \x1b[0;0;27;1;0;1_ -> \x1b (pressed) \x1b[0;0;91;1;0;1_ -> [ (pressed) \x1b[0;0;77;1;0;1_ -> M (pressed) \x1b[56;9;56;1;0;1_ -> 8 (pressed) \x1b[56;9;56;0;0;1_ -> 8 (released) \x1b[0;0;27;1;0;1_ -> \x1b (pressed) \x1b[0;0;91;1;0;1_ -> [ (pressed) \x1b[0;0;77;1;0;1_ -> M (pressed) \x1b[16;42;0;1;16;1_ -> ??? (pressed) \x1b[51;4;35;1;16;1_ -> # (pressed) \x1b[51;4;35;0;16;1_ -> # (released) \x1b[16;42;0;0;0;1_ -> ??? (released) ``` Which is, of course, entirely bogus. You're also going to see this for any DSR-CPR, any X11 focus mode, and any other types of answerback. **Excellent find!**
claunia commented 2026-01-31 06:48:50 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Apr 6, 2023):

Guessed the reason is something like it. Also was very surprised to see other escape sequences packed in the format of win32-input-mode :) I'm glad you're ready to solve it!

As for the use of this protocol in apps, there is a very interesting situation. To date, there are several protocols for extended keyboard support, and each has its own imperfections. kovidgoyal's kitty protocol looks overcomplicated. iTerm2 protocol is strongly tied to MacOS. far2l terminal extensions protocol is not yet very popular outside of far2l (although three applications already support it; I would be glad if you find an opportunity to implement it: it is nice and beautiful, and its keyboard part is based on the same KEY_EVENT_RECORD structure as win32-input-mode).

As a result, I fully admit that it is the win32-input-mode protocol that can become the de facto standard or one of standards.

Yes, I know that there are limitations associated with the fact that virtual scan codes are tied to keyboard layouts that the application on the other side of the terminal does not know anything about. Not a big problem — they are anyway not needed for anything other than distinguishing between the right and left Shift keys as there is a separate field for Unicode characters, and virtual key codes are suitable for implementing hotkeys that work independently of keyboard layout selected.

@unxed commented on GitHub (Apr 6, 2023): Guessed the reason is something like it. Also was very surprised to see other escape sequences packed in the format of win32-input-mode :) I'm glad you're ready to solve it! As for the use of this protocol in apps, there is a very interesting situation. To date, there are several protocols for extended keyboard support, and each has its own imperfections. kovidgoyal's [kitty](https://sw.kovidgoyal.net/kitty/keyboard-protocol/) protocol looks overcomplicated. [iTerm2](https://gitlab.com/gnachman/iterm2/-/issues/7440#note_129307021) protocol is strongly tied to MacOS. [far2l](https://github.com/elfmz/far2l/blob/master/WinPort/FarTTY.h) terminal extensions protocol is not yet very popular outside of far2l (although three applications already support it; I would be glad if you find an opportunity to implement it: it is nice and beautiful, and its keyboard part is based on the same KEY_EVENT_RECORD structure as win32-input-mode). As a result, I fully admit that it is the win32-input-mode protocol that can become the de facto standard or one of standards. Yes, I know that there are limitations associated with the fact that virtual scan codes are tied to keyboard layouts that the application on the other side of the terminal does not know anything about. Not a big problem — they are anyway not needed for anything other than distinguishing between the right and left Shift keys as there is a separate field for Unicode characters, and virtual key codes are suitable for implementing hotkeys that work independently of keyboard layout selected.
claunia commented 2026-01-31 06:48:51 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Apr 6, 2023):

Actually, far2l terminal extensions were designed to solve exactly the same problem as win32-input-mode: how to put all the power of the Windows console API (working with the clipboard, full support for keyboard input, etc) into the terminal escape sequences.

@unxed commented on GitHub (Apr 6, 2023): Actually, far2l terminal [extensions](https://github.com/elfmz/far2l/blob/master/WinPort/FarTTY.h) were designed to solve exactly the same problem as win32-input-mode: how to put all the power of the Windows console API (working with the clipboard, full support for keyboard input, etc) into the terminal escape sequences.
claunia commented 2026-01-31 06:48:51 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 6, 2023):

Actually, far2l terminal extensions were designed to solve exactly the same problem as win32-input-mode.

@unxed Note that the file you linked above is GPL-licensed source code, which I think can be legally problematic for some people to view.

@j4james commented on GitHub (Apr 6, 2023): > Actually, far2l terminal [extensions](https://github.com/elfmz/far2l/blob/master/WinPort/FarTTY.h) were designed to solve exactly the same problem as win32-input-mode. @unxed Note that the file you linked above is GPL-licensed source code, which I think can be legally problematic for some people to view.
claunia commented 2026-01-31 06:48:51 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Apr 6, 2023):

Oh, I certainly missed that, thanks!

@elfmz can you please as the only author change the license of FarTTY.h to 3-terms BSD? (looked into the commit list, I am also there, and I agree to relicensing under 3-terms BSD)

@unxed commented on GitHub (Apr 6, 2023): Oh, I certainly missed that, thanks! @elfmz can you please as the only author change the license of FarTTY.h to 3-terms BSD? (looked into the commit list, I am also there, and I agree to relicensing under 3-terms BSD)
claunia commented 2026-01-31 06:48:52 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Apr 6, 2023):

Also some (still incomplete, but better then nothing) far2l terminal extensions documentation written by me is available here:
https://github.com/cyd01/KiTTY/issues/74#issuecomment-626917718

Also you may take a look at the code of pull request implementing most important parts of far2l extensions in cyd01's kitty terminal and ssh client. It's a fork of putty, and putty is MIT licensed, so I guess it is totally legal to view such code even if you are developing some proprietary software.

Implementation itself:
https://github.com/cyd01/KiTTY/pull/357
Some important fixes:
https://github.com/cyd01/KiTTY/pulls?q=is%3Apr+author%3Aunxed

You can also search for "far2l" in commit log of Turbo Vision by @magiblot, it has implementation of same important parts of far2l tty extensions (clipboard, advanced keyboard support) on the side of TUI console app framework.
https://github.com/magiblot/tvision
far2l-releated code is under MIT:
https://github.com/magiblot/tvision/blob/master/COPYRIGHT

@unxed commented on GitHub (Apr 6, 2023): Also some (still incomplete, but better then nothing) far2l terminal extensions documentation written by me is available here: https://github.com/cyd01/KiTTY/issues/74#issuecomment-626917718 Also you may take a look at the code of pull request implementing most important parts of far2l extensions in cyd01's kitty terminal and ssh client. It's a fork of putty, and putty is MIT licensed, so I guess it is totally legal to view such code even if you are developing some proprietary software. Implementation itself: https://github.com/cyd01/KiTTY/pull/357 Some important fixes: https://github.com/cyd01/KiTTY/pulls?q=is%3Apr+author%3Aunxed You can also search for "far2l" in commit log of Turbo Vision by @magiblot, it has implementation of same important parts of far2l tty extensions (clipboard, advanced keyboard support) on the side of TUI console app framework. https://github.com/magiblot/tvision far2l-releated code is under MIT: https://github.com/magiblot/tvision/blob/master/COPYRIGHT
claunia commented 2026-01-31 06:48:52 +00:00
Author
Owner
Copy Link

@magiblot commented on GitHub (Apr 6, 2023):

Thanks for the mention, @unxed. I didn't know about win32-input-mode and it would be very interesting to support it in Turbo Vision.

Note that the FarTTY.h file you were talking about is already distributed under Public Domain terms since 70472d3b73.

@magiblot commented on GitHub (Apr 6, 2023): Thanks for the mention, @unxed. I didn't know about `win32-input-mode` and it would be very interesting to support it in Turbo Vision. Note that the FarTTY.h file you were talking about is already distributed under Public Domain terms since https://github.com/elfmz/far2l/commit/70472d3b7328df6b6451de60611e040da15a5715.
claunia commented 2026-01-31 06:48:53 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 6, 2023):

Note that the FarTTY.h file you were talking about is already distributed under Public Domain terms

Ah sorry. My bad. I just looked at the project home page and when I saw GPL I didn't look any further.

@j4james commented on GitHub (Apr 6, 2023): > Note that the FarTTY.h file you were talking about is already distributed under Public Domain terms Ah sorry. My bad. I just looked at the project home page and when I saw GPL I didn't look any further.
claunia commented 2026-01-31 06:48:53 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Apr 8, 2023):

kovidgoyal's kitty protocol looks overcomplicated

In fact, I slightly exaggerated the complexity of kovidgoyal's kitty keyboard protocol. Converting its escape sequences into a KEY_EVENT_RECORD is not so difficult. I proposed such code as PR to far2l, but as it is GPL licensed, I am publishing a parsing function alone (s is a C string with source kitty's esc sequence, l is a number of chars to parse) under CC0 license just for your interest:
https://gist.github.com/unxed/8649a6223e28312eb0df9ac11660b1d8

@unxed commented on GitHub (Apr 8, 2023): > kovidgoyal's [kitty](https://sw.kovidgoyal.net/kitty/keyboard-protocol/) protocol looks overcomplicated In fact, I slightly exaggerated the complexity of kovidgoyal's kitty keyboard protocol. Converting its escape sequences into a KEY_EVENT_RECORD is not so difficult. I proposed such code as [PR to far2l](https://github.com/elfmz/far2l/pull/1593), but as it is GPL licensed, I am publishing a parsing function alone (s is a C string with source kitty's esc sequence, l is a number of chars to parse) under CC0 license just for your interest: https://gist.github.com/unxed/8649a6223e28312eb0df9ac11660b1d8
claunia commented 2026-01-31 06:48:54 +00:00
Author
Owner
Copy Link

@magiblot commented on GitHub (Oct 19, 2023):

Given the advantages win32-input-mode provides, I chose to add support for it in Turbo Vision, including a work-around for the re-encoded mouse events this issue is about.

This is especially useful for non-Windows applications running in WSL or via SSH. However, it is likely not the ultimate solution to the problem of extended keyboard support, given that if an application which enabled win32-input-mode gets unexpectedly killed or the connection breaks, then the current shell may become permanently unusable (it has happened a few times to me as I was testing). As I understand, this is not a problem win32-input-mode is intended to address. Although I also wonder if this can be solved at the protocol level.

@magiblot commented on GitHub (Oct 19, 2023): Given the advantages win32-input-mode provides, I chose to add support for it in Turbo Vision, including a work-around for the re-encoded mouse events this issue is about. This is especially useful for non-Windows applications running in WSL or via SSH. However, it is likely not the ultimate solution to the problem of extended keyboard support, given that if an application which enabled win32-input-mode gets unexpectedly killed or the connection breaks, then the current shell may become permanently unusable (it has happened a few times to me as I was testing). As I understand, this is not a problem win32-input-mode is intended to address. Although I also wonder if this can be solved at the protocol level.
claunia commented 2026-01-31 06:48:55 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Mar 14, 2024):

I chose to add support for it in Turbo Vision, including a work-around for the re-encoded mouse events this issue is about

Exact commit:
ae1a6859b4

@unxed commented on GitHub (Mar 14, 2024): > I chose to add support for it in Turbo Vision, including a work-around for the re-encoded mouse events this issue is about Exact commit: https://github.com/magiblot/tvision/commit/ae1a6859b48806dcd13d652d451eca28b934a539
claunia commented 2026-01-31 06:48:55 +00:00
Author
Owner
Copy Link

@atolismesh commented on GitHub (Mar 17, 2024):

I looked in the WinDbg debugger to see what was going on. Spoils mouse messages OpenConsole.exe from Windows Terminal, not conhost.exe as I thought before. Something like the following happens: One part of the program reads events from the keyboard, mouse, etc., then puts them in an internal event queue marked with the event type. Then this queue is processed and, depending on the selected terminal emulation, it is converted into a CSI etc sequence. Mouse sequences are correctly converted for win32input to the ESC[Mbxy format we need. The event type marks are already lost in this case. All of this is queued up for output.
But then, in a different thread (second handler) VtInputThread::DoReadInput(), the "write queue" starts reading from this queue, but there's no info about the event type anymore. The handler just sees ESC and converts it to CSI again, thinking it's keyboard input. So the results get sent to our terminal and far2l.Yeah, if we'd totally disabled the second one, it would've helped us, since the first one already had everything encoded for us.

@atolismesh commented on GitHub (Mar 17, 2024): I looked in the WinDbg debugger to see what was going on. Spoils mouse messages OpenConsole.exe from Windows Terminal, not conhost.exe as I thought before. Something like the following happens: One part of the program reads events from the keyboard, mouse, etc., then puts them in an internal event queue marked with the event type. Then this queue is processed and, depending on the selected terminal emulation, it is converted into a CSI etc sequence. Mouse sequences are correctly converted for win32input to the ESC[Mbxy format we need. The event type marks are already lost in this case. All of this is queued up for output. But then, in a different thread (second handler) VtInputThread::DoReadInput(), the "write queue" starts reading from this queue, but there's no info about the event type anymore. The handler just sees ESC and converts it to CSI again, thinking it's keyboard input. So the results get sent to our terminal and far2l.Yeah, if we'd totally disabled the second one, it would've helped us, since the first one already had everything encoded for us.
claunia commented 2026-01-31 06:48:56 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Mar 19, 2024):

Fixed on far2l's side:
https://github.com/elfmz/far2l/pull/2085

Thanks @magiblot for inspiration!

@unxed commented on GitHub (Mar 19, 2024): Fixed on far2l's side: https://github.com/elfmz/far2l/pull/2085 Thanks @magiblot for inspiration!
claunia commented 2026-01-31 06:48:56 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Aug 19, 2024):

Sorry for using this issue to relate that the mouse events are not sent when the mouse is outside the top of the WT, no mater I'm using win32-input-mode or using virtual terminal sequences. It only send events inside and outside left, bottom and right, but not when it's outside of the top window.
With the conhost this doesn't happens, so I imagine that it's only a WT issue. Thanks for your attention.

@BDisp commented on GitHub (Aug 19, 2024): Sorry for using this issue to relate that the mouse events are not sent when the mouse is outside the top of the WT, no mater I'm using win32-input-mode or using virtual terminal sequences. It only send events inside and outside left, bottom and right, but not when it's outside of the top window. With the `conhost` this doesn't happens, so I imagine that it's only a WT issue. Thanks for your attention.
claunia commented 2026-01-31 06:48:57 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 19, 2024):

Sorry for using this issue to relate that the mouse events are not sent when the mouse is outside the top of the WT, no mater I'm using win32-input-mode or using virtual terminal sequences. It only send events inside and outside left, bottom and right, but not when it's outside of the top window. With the conhost this doesn't happens, so I imagine that it's only a WT issue. Thanks for your attention.

@bdisp Please just file a new issue. It is just as much work as adding a comment to an existing unrelated issue.

@DHowett commented on GitHub (Aug 19, 2024): > Sorry for using this issue to relate that the mouse events are not sent when the mouse is outside the top of the WT, no mater I'm using win32-input-mode or using virtual terminal sequences. It only send events inside and outside left, bottom and right, but not when it's outside of the top window. With the `conhost` this doesn't happens, so I imagine that it's only a WT issue. Thanks for your attention. @bdisp Please just file a new issue. It is just as much work as adding a comment to an existing unrelated issue.
claunia commented 2026-01-31 06:48:57 +00:00
Author
Owner
Copy Link

@BDisp commented on GitHub (Aug 19, 2024):

@BDisp Please just file a new issue. It is just as much work as adding a comment to an existing unrelated issue.

I opened this issue #17744. It gave me much more work but worth it. Thanks.

@BDisp commented on GitHub (Aug 19, 2024): > @BDisp Please just file a new issue. It is just as much work as adding a comment to an existing unrelated issue. I opened this issue #17744. It gave me much more work but worth it. Thanks.
claunia commented 2026-01-31 06:48:57 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Oct 5, 2024):

Should be fixed in latest Pre-release (v1.22.2702.0), see
https://github.com/microsoft/terminal/blob/v1.22.2702.0/src/terminal/adapter/IInteractDispatch.hpp

In latest Release (v1.21.2701.0) still don't,
https://github.com/microsoft/terminal/blob/v1.21.2701.0/src/terminal/adapter/IInteractDispatch.hpp

WriteStringRaw presence is marker of fix applied.

@unxed commented on GitHub (Oct 5, 2024): Should be fixed in latest Pre-release (v1.22.2702.0), see https://github.com/microsoft/terminal/blob/v1.22.2702.0/src/terminal/adapter/IInteractDispatch.hpp In latest Release (v1.21.2701.0) still don't, https://github.com/microsoft/terminal/blob/v1.21.2701.0/src/terminal/adapter/IInteractDispatch.hpp `WriteStringRaw` presence is marker of fix applied.
claunia commented 2026-01-31 06:48:57 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 5, 2024):

WriteStringRaw presence is marker of fix applied.

WriteStringRaw is also an indicator of the completely rewritten input engine in 1.22, so it’s not a straightforward backport. We aren’t intending to fix this for 1.21.

@DHowett commented on GitHub (Oct 5, 2024): > `WriteStringRaw` presence is marker of fix applied. `WriteStringRaw` is also an indicator of the completely rewritten input engine in 1.22, so it’s not a straightforward backport. We aren’t intending to fix this for 1.21.
claunia commented 2026-01-31 06:48:58 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Oct 5, 2024):

Thanks for fixing this anyway!

@unxed commented on GitHub (Oct 5, 2024): Thanks for fixing this anyway!
claunia commented 2026-01-31 06:48:58 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Oct 8, 2024):

Clipboard paste problem in win32-input-mode is caused by the same input events double encoding issue:
https://github.com/microsoft/terminal/issues/17656

@unxed commented on GitHub (Oct 8, 2024): Clipboard paste problem in win32-input-mode is caused by the same input events double encoding issue: https://github.com/microsoft/terminal/issues/17656
claunia commented 2026-01-31 06:48:58 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Oct 12, 2024):

Unfortunately, the mouse and double encoding bug in WT-1.22.2702 is still present, although it manifests differently and can be worked around.

I performed three tests. In all screenshots, the embedded Far2l GUI terminal at the top serves as a reference implementation of win32-input-mode, which doesn't suffer from this bug. The Windows Terminal is at the bottom.

The first test uses the X10 mouse protocol. Here, WT doesn't wrap the \x1b[M marker in win32-input-mode, but for some reason encodes the command parameters.

The second test enables SGR extended mouse reporting. And what do we see? The commands are transmitted exactly as they should be, without any extra transformations.

The third test uses bracketed paste. Predictably, the start and end paste markers are not encoded, but the content is.

Apparently, WT mistakenly interprets \x1b[M as some other code at some stage, and treats its parameters as regular character input. Since everyone uses SGR for mouse input now, the bug is insignificant, and if console program has a problem with this, it's easier for it to implement SGR than to create workarounds for double decoding.

For the tests, the source code from the ticket's initial message was used, with the addition of necessary instructions to support mouse move, mouse drag, SGR extended mouse reporting, and bracketed paste.

fprintf(stderr, "\x1b[?1002h");
fprintf(stderr, "\x1b[?1003h");
fprintf(stderr, "\x1b[?1006h");
fprintf(stderr, "\x1b[?2004h");

Image
Image
Image

@unxed commented on GitHub (Oct 12, 2024): Unfortunately, the mouse and double encoding bug in WT-1.22.2702 is still present, although it manifests differently and can be worked around. I performed three tests. In all screenshots, the embedded Far2l GUI terminal at the top serves as a reference implementation of win32-input-mode, which doesn't suffer from this bug. The Windows Terminal is at the bottom. The first test uses the X10 mouse protocol. Here, WT doesn't wrap the \x1b[M marker in win32-input-mode, but for some reason encodes the command parameters. The second test enables SGR extended mouse reporting. And what do we see? The commands are transmitted exactly as they should be, without any extra transformations. The third test uses bracketed paste. Predictably, the start and end paste markers are not encoded, but the content is. Apparently, WT mistakenly interprets \x1b[M as some other code at some stage, and treats its parameters as regular character input. Since everyone uses SGR for mouse input now, the bug is insignificant, and if console program has a problem with this, it's easier for it to implement SGR than to create workarounds for double decoding. For the tests, the source code from the ticket's initial message was used, with the addition of necessary instructions to support mouse move, mouse drag, SGR extended mouse reporting, and bracketed paste. ``` fprintf(stderr, "\x1b[?1002h"); fprintf(stderr, "\x1b[?1003h"); fprintf(stderr, "\x1b[?1006h"); fprintf(stderr, "\x1b[?2004h"); ``` ![Image](https://github.com/user-attachments/assets/e2bcfd46-f84f-4fe2-b537-938e536fa21e) ![Image](https://github.com/user-attachments/assets/89fca6e2-fbde-4fbc-99d4-a8196b0b8f4f) ![Image](https://github.com/user-attachments/assets/557794ed-eed4-4776-8f1b-8e302ae0bdcf)
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 Area-Input Area-VT Help Wanted Issue-Bug Product-Conhost Product-Conpty
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#19617
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?