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

Alt arrow keys print extra characters #3101

Closed
paulwhiting opened this issue Oct 7, 2019 · 9 comments · Fixed by #3117
Closed

Alt arrow keys print extra characters #3101

paulwhiting opened this issue Oct 7, 2019 · 9 comments · Fixed by #3117
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements 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

@paulwhiting
Copy link

Terminal Version: 0.5.2762.0
Microsoft Windows [Version 10.0.18362.356]

Steps to reproduce

Open terminal. Press alt-up, alt-down, alt-right, alt-left.

(For byobu: start byobu with 'byobu'. Press F2 to add a new tab. Press alt-right and alt-left to switch between tabs.)

Expected behavior

Observed behavior

  • c:\windows\system32\bash.exe: ABCD is printed out as expected.
  • c:\windows\system32\bash.exe in byobu: Byobu tabs are switched on alt-left and alt-right. (Only a single session is running so alt-up and alt-down just error out as expected.) No additional characters are printed out, as expected.
  • Windows Powershell terminal (run->powershell): Nothing is printed out. (Expected? I don't know.)
  • Terminal App powershell: ☻♠♦ is printed out.
  • Terminal App ubuntu: A◘B☻C♠D♦ is printed out.
  • Terminal App ubuntu in byobu: Byobu tabs are are switched as expected, BUT when alt is released one of ◘☻♠♦ is printed out depending on which arrow key was pressed last.
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Oct 7, 2019
@rideron89
Copy link

rideron89 commented Oct 7, 2019

I'm having the same issue. Happens in both fish and bash.

I use alt-left and alt-right to navigate through words on a command.

Terminal version: 0.5.2762.0
Windows 10 version 18362.388 (1903)

@DHowett-MSFT
Copy link
Contributor

Confirmed! Possible regression from #2836 (/cc @lhecker)?

@DHowett-MSFT DHowett-MSFT added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. labels Oct 7, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 7, 2019
@DHowett-MSFT DHowett-MSFT added Needs-Tag-Fix Doesn't match tag requirements and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 7, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 7, 2019
@DHowett-MSFT DHowett-MSFT added this to the Terminal-1910 milestone Oct 7, 2019
@lhecker
Copy link
Member

lhecker commented Oct 8, 2019

@DHowett-MSFT This issue is caused by the use of ToUnicodeEx(), which has the following warning...

As ToUnicodeEx translates the virtual-key code, it also changes the state of the kernel-mode keyboard buffer. This state-change affects dead keys, ligatures, alt+numpad key entry, and so on. It might also cause undesired side-effects if used in conjunction with TranslateMessage (which also changes the state of the kernel-mode keyboard buffer).

I'll open a PR.

@paulwhiting I was not able to exactly replicate your observed behavior. Is there a way to switch between "keypad mode" on/off? I'm "Press[ing] alt-up, alt-down, alt-right, alt-left" (in that order) and I'm not really certain why I'm getting these different results:

  • C:\Windows\System32\bash.exe: Alt+Up/Down causes a beep (or "bing") and Alt+Left/Right jumps between words
  • Terminal App powershell: ◘☻♠♦ is printed out.
  • Terminal App ubuntu: ♦◘☻♠ is printed out.

@ghost ghost added the In-PR This issue has a related PR label Oct 8, 2019
@paulwhiting
Copy link
Author

paulwhiting commented Oct 9, 2019

I believe num lock should do what you want? My keyboard doesn't have a numeric keypad, just standalone arrow keys. You're not seeing the ABCD characters because your underlying shell is handling those. It's the extra one of ♦◘☻♠ that pops up after letting go of alt that's the problem.

@david50407
Copy link

david50407 commented Oct 15, 2019

In my case, the extra keystroke will happens when I "release the Alt key" after pressing Alt+Left/Right/Up/Down.
If I don't release Alt key, the control key \cA \cB \cC \cD won't come out.

@sivaramn
Copy link

can confirm, I too face this. Within tmux, if i switch panes using Alt+direction keys, i get funny chars on the command line

@daveshih01
Copy link

Hi folks, sorry for stating the obvious. Please review/approve the PR so this can be addressed. Thanks!

@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 Nov 13, 2019
zadjii-msft pushed a commit that referenced this issue Nov 13, 2019
## Summary of the Pull Request

This PR potentially fixes #3101.

## PR Checklist
* [x] Closes #3101.
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

## Detailed Description of the Pull Request / Additional comments

This PR fixes #3101 by setting flag 0 in `ToUnicodeEx()` even though the documentation says "If bit 0 is set, a menu is active.". I'm not 100% sure why it works, but it definitely does in this case.
I thought that bit 2, which claims that "keyboard state is not changed" would be sufficient to prevent this from happening, but it seems that's not the case.

I believe this PR should be verified by a developer at Microsoft who's familiar with the internal workings of `ToUnicodeEx()`.
We need this function (or something similar) to translate Alt+Key combinations to proper unicode.
But at the same time it should not send us any additional IBM-style Alt Codes to our character handler if that translation fails (and `ToUnicodeEx()` returns 0).

## Validation Steps Performed

See #3101 for more information. I ensured that Alt+Arrow-Key combinations do not print ◘☻♠♦ anymore.
@daveshih01
Copy link

Thanks, everyone!

@ghost
Copy link

ghost commented Nov 26, 2019

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

Handy links:

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-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements 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.

8 participants