win32-input-mode: clipboard paste weird escape sequences

[ClusterM]

Windows Terminal version

1.21.1772.0

Windows build number

10.0.22631.3958

Other Software

standard ssh, Linux

Steps to reproduce

1. Copy "test" string to clipboard
2. Run Terminal
3. Connect to Linux via SSH
4. Type printf "\x1b[?9001h" to enable win32-input-mode
5. Right-click on the terminal window to paste text from a clipboard

Expected Behavior

;4;20;116;1;0;1_;4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_;3;31;115;1;0;1_;3;31;115;0;0;1_;4;20;116;1;0;1_;4;20;116;0;0;1_

It's t, e, s, t key presses.

Actual Behavior

;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;48;1;0;1_;0;126;1;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_3;31;115;1;0;1_3;31;115;0;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;49;1;0;1_;0;126;1;0;1_

Decoded:

| Sequence          | Vk | Sc  | Uc  | Kd   | Cs | Rc | Description           |
|-------------------|----|-----|-----|------|----|----|-----------------------|
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;18;101;1;0;1_`  | 18 | 101 | e   | Down | 0  | 1  | Key e pressed         |
| `;18;101;0;0;1_`  | 18 | 101 | e   | Up   | 0  | 1  | Key e released        |
| `;3;31;115;1;0;1_`| 3  | 31  | s   | Down | 0  | 1  | Key s pressed         |
| `;3;31;115;0;0;1_`| 3  | 31  | s   | Up   | 0  | 1  | Key s released        |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;49;1;0;1_`    | 0  | 49  | 1   | Down | 1  | 1  | Key 1 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |

As you can see, there are much more key codes. Why?

[DHowett]

So, the "press" and "release" for each key is expected. The encoding of \x1b[200~ (and ...201~) as Win32 key events is not entirely expected in normal cases.

However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in INPUT_RECORD format.

You are getting the bracketed paste sequences \x1b[200~ and \x1b[201~ in the same way Windows applications using the ReadConsoleInput API do: VT, encoded as key presses.

We have work on the books to improve this (not translating VT sequences we generate when the application does not need them), but that is largely irrespective of Win32 input mode, and it is low priority because Windows applications already work this way.

TL;DR: When you request WIN32IM, you get the same kinds of input records as Console applications. That includes "key press" encodings for VT sequences. 😄

[ClusterM]

However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in INPUT_RECORD format.

But I have only clean text in my clipboard and I want to paste it only. Terminal should enter this text as key presses and nothing else. This problem affects far2l:

And I'm not sure if it's far2l's bug or Terminal's bug.

[lhecker]

The win32-input-mode was primarily designed as a private ¹ protocol between parts that make up Windows Terminal (ConPTY specifically). In that context it works perfectly, and this issue doesn't occur. The way I see it, it's a bug that clipboard pastes and VT sequences are encoded with the win32-input-mode format, because the spec explicitly says it's for keyboard input. I'd like to change this, but I'm not sure when I'd get to that.

I'm also a bit squirmish about working on this space, because I'm still concerned about claiming one of the very scarce terminators (_) and about future compatibility between systems of different versions and keyboard layouts. Personally, I'd prefer if applications could not request the win32-input-mode in the first place and it remained a strictly private protocol for the parts that make up Windows Terminal (and other terminals based on ConPTY). I know that various important applications have come to rely on this mode which makes me particularly worried, because I wonder now if it's too late to put a lid back onto this "leak". It's also not trivially possible to do so in the first place because ConPTY -> WSL -> ConPTY should work.

Footnotes

1. "private" is a poor choice of words, as explained by Dustin below. ↩

[DHowett]

private

I wouldn't call it private; it's just a protocol for high fidelity Console eventing that terminals on windows can use if they need to represent key make and break sequences.

Terminal should enter this text as key presses and nothing else.

It is. But Windows console applications don't actually read text, they read true key press and release events, even when they are reading VT. There is a bug today where the key press and release events we synthesize for VT are re-encoded as Win32-input-mode events even when the application has indicated that it wants direct VT input.

I'm not talking about our ideal state, just what we have today.

What we have today has some gaps because it was not designed to be an application-facing protocol. That's fine; if we want to make it one we can fix the bugs and pursue standardization.

[DHowett]

And I'm not sure if it's far2l's bug

Thinking about this more: if the shell inside far2l is requesting bracketed paste mode, and far2l is requesting Win32 input mode, then regardless of how the escape sequences are translated I would expect far2l to unencapsulate them. That's what Windows console applications do, when they get them in INPUT_RECORD format (which is the Windows API equivalent.)

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

[atolismesh]

I think that this issue is more complex.
Details are here -· Issue ·#15083 (comment)
"I looked in the WinDbg debugger to see what was going on. ..... "

[DHowett]

Thanks for finding that! It's fundamentally the same issue. Once one of us is back in the office we'll deduplicate them and migrate all the relevant data over.

[ClusterM]

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

Yes, it was terrible. I fixed it, waiting for pull request merge :)

[unxed]

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

Am I correct in understanding that pull request #17833 solves this problem too?

@DHowett