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.

Sign up for GitHub

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

Jump to bottom

Extra character inserted when writing ~ or ` with vscode and french keyboard layout #391

Closed
vlj opened this issue Mar 21, 2019 · 8 comments
Closed

Extra character inserted when writing ~ or ` with vscode and french keyboard layout #391

vlj opened this issue Mar 21, 2019 · 8 comments
Assignees
@zadjii-msft
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Conpty For console issues specifically related to conpty Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Work-Item It's being tracked by an actual work item internally. (to be removed soon)
Milestone
Terminal v1.0

Comments

@vlj
Copy link

vlj commented Mar 21, 2019

  • Your Windows build number: My build is : Microsoft Windows [version 10.0.18362.1]
    Using vscode 1.32.3 with conpty enabled.

  • What you're doing and what's happening:
    When trying to type some specific character with a french keyboard layout, an extra character ("é") is added. For now I spotted 2 characters, ~ and . More precisely, if I press "alt gr" and 2 at the same time, a "é" is added. If I then press space, then I have "é~" in the prompt. If I press "alt gr" and seven at the same time, a "é" is added. If I then press space, then I have "é" in the prompt.

3Pqo1WSEh2

  • What's wrong / what should be happening instead:
    What should happen is that no ~ is added.
@vlj
Copy link
Author

vlj commented Mar 21, 2019

Note that it doesn't happen if I disable conpty.
I didn't find a similar issue (it's not a newline)

@zadjii-msft
Copy link
Member

I've filed MSFT:20921862 internally to make sure this gets investigated.

@zadjii-msft zadjii-msft added Work-Item It's being tracked by an actual work item internally. (to be removed soon) Product-Conpty For console issues specifically related to conpty labels Mar 21, 2019
@vlj
Copy link
Author

vlj commented May 9, 2019

I don't know where the issue is in the stack, but just in case, it's still present with Terminal app (master, checked yesterday).

@zadjii-msft zadjii-msft added this to the Windows Terminal v1.0 milestone May 9, 2019
@zadjii-msft zadjii-msft added the Issue-Bug It either shouldn't be doing this or needs an investigation. label May 9, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-Input Related to input processing (key presses, mouse, etc.) and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 18, 2019
@LiHRaM
Copy link

LiHRaM commented Jun 29, 2019

Using Danish keyboard results in invisible character being inserted when using alt gr to compose letters.

# cmd.exe
C:\Users\hilma\git>ver
Microsoft Windows [Version 10.0.18922.1000]
C:\Users\hilma\git>¨~ 

# wsl
$ cd ~
-bash: cd: $'\250~': No such file or directory

In practice I've had to switch to other terminals to use | (pipes) and vim, as it exists insert mode whenever I compose with alt gr.

@LRA-QC
Copy link

LRA-QC commented Jul 2, 2019

I cannot use any characters composed with ALT GR.. including @ and [ ]

@fle108
Copy link

fle108 commented Oct 2, 2019

still present vscode 1.38.1

@lhecker lhecker mentioned this issue Jan 12, 2020
Merged
3 tasks
@cinnamon-msft cinnamon-msft added Priority-0 Bugs that we consider release-blocking/recall-class (P0) v1-Scrubbed labels Jan 28, 2020
@zadjii-msft zadjii-msft self-assigned this Mar 26, 2020
ghost pushed a commit that referenced this issue Apr 7, 2020
@lhecker
Delegate all character input to the character event handler (#4192)
a9c9714 
My basic idea was that `WM_CHAR` is just the better `WM_KEYDOWN`.
The latter fails to properly support common dead key sequences like in
#3516.

As such I added some logic to `Terminal::SendKeyEvent` to make it return
false if the pressed key represents a printable character.
This causes us to receive a character event with a (hopefully) correctly
composed code unit, which then gets sent to `Terminal::SendCharEvent`.
`Terminal::SendCharEvent` in turn had to be modified to support
potentially pressed modifier keys, since `Terminal::SendKeyEvent` isn't
doing that for us anymore.
Lastly `TerminalInput` had to be modified heavily to support character
events with modifier key states. In order to do so I merged its
`HandleKey` and `HandleChar` methods into a single one, that now handles
both cases.
Since key events will now contain character data and character events
key codes the decision logic in `TerminalInput::HandleKey` had to be
rewritten.

## PR Checklist
* [x] CLA signed
* [x] Tests added/passed
* [x] I've discussed this with core contributors already.

## Validation Steps Performed

* See #3516.
* I don't have any keyboard that generates surrogate characters. Due to
  this I modified `TermControl::_SendPastedTextToConnection` to send the
  data to `_terminal->SendCharEvent()` instead. I then pasted the test
  string ""𐐌𐐜𐐬" and ensured that the new `TerminalInput::_SendChar`
  method still correctly assembles surrogate pairs.

Closes #3516
Closes #3554 (obsoleted by this PR)
Potentially impacts #391, which sounds like a duplicate of #3516
@DHowett-MSFT
Copy link
Contributor

Yes, this was fixed by #4192. Verified in VSCode, Putty, and Terminal. VSCode now produces qq for AltGr-2 Q, but no other terminal emulators using the same infrastructure do so. Any further bugs here are liable to be upstream's fault.

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Apr 7, 2020
@DHowett-MSFT DHowett-MSFT added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed Needs-Tag-Fix Doesn't match tag requirements labels Apr 7, 2020
@DHowett-MSFT
Copy link
Contributor

FWIW: I can't even reproduce this with the original inbox console host. Perhaps this was always VS Code's fault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@zadjii-msft zadjii-msft

Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Conpty For console issues specifically related to conpty Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Work-Item It's being tracked by an actual work item internally. (to be removed soon)
Projects
None yet
Milestone
Terminal v1.0
Development

No branches or pull requests
8 participants
@vlj @DHowett-MSFT @miniksa @zadjii-msft @LRA-QC @LiHRaM @fle108 @cinnamon-msft