TerminalControl handles ALT+NUMPAD input poorly

[leoniDEV]

When the user enters Alt-123 it looks like we're doing this:

• Sending ESC 1
• Sending 2
• Sending 3
• Sending whichever character Alt-123 corresponds to.

Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character 123 being added to the buffer 123 times.

We should definitely fix that.

original content

Environment

Windows build number: 10.0.18922.1000 and 10.0.18362.175
Windows Terminal version (if applicable): 0.2.1715.0

Any other software?
Powershell Core 7.0.0-preview.1
Powershell Core 6.2.1
Windows Powershell 5.1

Steps to reproduce

• Open Powershell (whatever version listed above) session in the Terminal
• try to insert an ascii char by:
  • press and hold ALT key
  • digit whatever number (for example 126 corresponding to ~)

Expected behavior

a tilde (~) is inserted

Actual behavior

127 tildes are inserted

The same thing happens for all the versions of Powershell listed above

[Shorotshishir]

Weird behavior in all terminals: Numpad on/off state changes the output

• WSL is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓

• CMD is making adding the number corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓

• PowerShell is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) character won't show. ↓↓

[DHowett-MSFT]

When the user enters Alt-123 it looks like we're doing this:

• Sending ESC 1
• Sending 2
• Sending 3
• Sending whichever character Alt-123 corresponds to.

Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character 123 being added to the buffer 123 times.

We should definitely fix that.

[lhecker]

If someone (potentially inexperienced with this project) wants to debug this issue they might find the following line of interest:

terminal/src/terminal/input/terminalInput.cpp

Line 428 in 5dd1f8d

_SendEscapedInputSequence(keyEvent.GetCharData());

It's the one responsible for generating the escape codes.

The following callback then sends these further to the shell:

terminal/src/cascadia/TerminalCore/Terminal.cpp

Lines 53 to 60 in 5dd1f8d

	auto passAlongInput = [&](std::deque<std::unique_ptr<IInputEvent>>& inEventsToWrite) {
	if (!_pfnWriteInput)
	{
	return;
	}
	std::wstring wstr = _KeyEventsToText(inEventsToWrite);
	_pfnWriteInput(wstr);
	};

(_pfnWriteInput goes straight to TermControl::_SendInputToConnection in our case which is then the last stage before the shell I suppose).
If you hold Alt and enter 64 on the Numpad it will then generate the following input sequence for the shell: \x1b6\x1b4@ (\x1b being the escape character).

I'm personally not entirely certain where the @ is coming from, but I suspect this is generated by the Operating System and sent as a WM_CHAR message to the application here:

terminal/src/cascadia/TerminalControl/TermControl.cpp

Lines 564 to 565 in 5dd1f8d

	void TermControl::_CharacterHandler(winrt::Windows::Foundation::IInspectable const& /*sender*/,
	Input::CharacterReceivedRoutedEventArgs const& e)

If I'm correct, then to go fully UNIXy we might want to prevent the OS from translating Alt+Numpad for us (however one would do that). Otherwise we should disable the call to _SendEscapedInputSequence I guess.

[ghost]

🎉This issue was addressed in #4965, which has now been successfully released as Windows Terminal Preview v0.10.781.0.:tada:

Handy links:

• Release Notes
• Store Download

[ilqvya]

Still reproduces:

[ilqvya]

[ilqvya]

plz, reopen @avdi @shanselman @timheuer @alecthegeek @atifaziz @leonMSFT @leoniDEV

[leonMSFT]

Sorry about it still happening @effolkronium! From your repro, it almost looks like your Terminal never got the PR that fixed the thing where digit-argument starts #4965. I tried to repro this on a bunch of my machines. A couple of them are running a version of Terminal that's further ahead, but I have a couple that are also running 0.10.781.0, and it's working fine for me (so that's a real head scratcher). 😢 I'm also asking the rest of the team to see if they can repro what you're seeing, and so far no luck, I can't get a reliable repro for what you're seeing. For now the only thing I can suggest is I'd like for you to try reinstalling Terminal if you get a chance (this is a wild guess that may or may not work).

[ilqvya]

@leonMSFT

I think ALT worked well day or week ago for me.

as i can see terminal got the update at the end of last month. So i think it was ok with this version some time

I just re -installed the Terminal but the bug still reproduces. ^(((

...

Also it doesn't work with update before current. Maybe some OS or third party app impact...

I'll try to investigate a bit, maybe even debug the terminal by myself

[ilqvya]

Hmm, seems it do not recognize alt at all (the breakpoint when i press alt and then number)

[ilqvya]

Ok, so this is my VirtKey for number 2

The check for NumberPad0 - NumberPad9 fails. I think it's because i press numbers below F row. not numpad.

[ilqvya]

Well, ignoring VirtualKey::Number0 - VirtualKey::Number9 doesn't help

it passes check but tab switch still no happening.

@leonMSFT

could you suggest what i should debug or look to for fix ?

[DHowett-MSFT]

dude, Alt NUMPAD input only works if you use the number pad. The numbers below the F keys aren’t the number pad.

[ilqvya]

dude, Alt NUMPAD input only works if you use the number pad. The numbers below the F keys aren’t the number pad.

Man, it worked well all the time when I used this app in past. I have no numpud on my keyboard

[lhecker]

Correct me if I'm wrong, but...

@effolkronium Unfortunately if that has ever worked it must've been a bug anyways. Entering Alt codes with regular number keys most definitely wasn't a feature. I'm not aware of Windows supporting Alt codes with regular number keys in the first place.
Even DEC's later terminals (which this project is replicating to a large extent) only supported composition using the numeric keypad.

Some keyboards with Fn keys support entering numeric keypad codes using the main keyboard.
On one keyboard I had pressing FnM was the same as pressing Numpad0.
If your keyboard doesn't support that either you'll unfortunately not be able to enter Alt codes.
Your only alternative is Win.. As I said above, entering Alt codes with regular number keys most likely is not something this project will support in the future, as Windows itself normally doesn't support that either.

[ilqvya]

oK, so it works if i press alt+ctr+num.

i think ticket should be closed

[DHowett-MSFT]

@lhecker thanks for the excellent write up
@effolkronium thanks for confirming that you found a solution :)