AltGr invokes Ctrl+Alt shortcuts

[amcsi]

• VSCode Version: 1.23.1
• OS Version: Windows 10

Steps to Reproduce:

1. Set keyboard to the Hungarian keyboard layout
2. Make sure there is a keyboard shortcut set to Ctrl+Alt+B
3. Press AltGr+B in the editor

Expected: a { is typed
Actual: The Ctrl+Alt+B shortcut is invoked

This issue is basically the same as #41225

Whoever closed that ticket quoted that Ctrl+Alt and AltGr should be equivalents based on this wikipedia article, but I digress.
It's true that even on Windows you can press Ctrl+Alt+<key> to get the AltGr+<key> equivalent character typed, however it should not be true the other way around.
If you read the wikipedia article, it says that the ability was there to make it possible for otherwise AltGr-only characters to be typed. It does not say though that AltGr should invoke the hotkeys that are for Ctrl+Alt. If you did, you make it impossible for people using foreign keywords to use Ctrl+Alt shortcut sequences. Windows most certainly does not emit Ctrl+Alt on press of AltGr!

For reference, in IntelliJ there is a custom option you can enable to make sure AltGr does not emit Ctrl+Alt events: https://youtrack.jetbrains.com/issue/IDEA-91975#comment=27-384169

[alexdima]

@amcsi I agree with you, but this is not under our (VS Code) control and we cannot change this. We are built with Electron, which is built on top of Chromium, which follows w3c standards.

Here is where we read a keyboard event sent our way by Chromium. Observe the lack of doing anything with AltGr. We simply read the modifier flags as we receive the event :
https://github.com/Microsoft/vscode/blob/baf3b60651bbfac50d8297b07e71240232316de9/src/vs/base/browser/keyboardEvent.ts#L230-L233

When you press AltGr+B, the event coming our way contains the key code for B and the flags for altKey and ctrlKey are set to true. i.e. there is no way at our abstraction level to determine if this keypress came from AltGr+B or Ctrl+Alt+B.

[amcsi]

@alexandrudima I don't know that much about Chromium internals, but I would think the problem is with your abstraction layer.

On this website I can see that it is possible in Chrome to differentiate between if an alt key press was from the right side of the keyboard.

In the screenshot, the bottom two keyup events are me just pressing down AltGr; the keydowns higher up are left Ctrl+Alt.
True that Ctrl is always shown as pressed, but together with the knowledge that out of the Alt keys the right one is down, you could ignore that combined with the Ctrl key being pressed down for the purposes of modifier keys for shortcuts.

[alexdima]

@amcsi

I'm using an ISO keyboard with the German (Swiss) keyboard layout.

Here is me pressing AltGr+S on the physical keyboard:

Here is me pressing Ctrl+Alt+S on the physical keyboard:

Here is me pressing AltGr+S using the On-Screen Keyboard:

Here is me pressing Ctrl+Alt+S using the On-Screen Keyboard:

---

Our keybinding dispatching executes on keydown, specifically on the keydown at number 3 in all the screenshots above. Note how the row number 3 is identical in all cases, and how Chromium reports the modifier AltGraph in all 4 cases.

[amcsi]

@alexandrudima I know for a fact that unfortunately AltGraph is not a reliable way to detect AltGr, evident also by this StackOverflow post: https://stackoverflow.com/questions/10657346/detect-alt-gr-alt-graph-modifier-on-key-press

What I wanted to bring to your attention though is the code column within the cyan UI Events; you can tell that an Alt is Right by it saying AltLeft... and good that you brought up the on-screen keyboard where apparently it's neither left nor right for AltGr.

This would probably require additional work to keep track of whether the left or right Alt was pressed down/released in the keydown/keyup events, because probably there's not enough information just looking at the keypress event with its .xyKey properties.

[alexdima]

Currently, keypress dispatching is stateless. i.e. the event coming in from the browser is treated independent from other events (with the notable exception of chords -- but that has nothing to do with tracking modifiers). In other words, all the data and only the data of event number 3 above is used to dispatch Ctrl+Alt+S

Anyways, in my experience, tracking modifiers manually is extremely error prone. (i.e. by manual I mean looking for keydown and keyup events for the modifiers keys and trying to maintain an application level modifier state).

The reason is that surprisingly often, keydowns/keyups go missing and don't reach us.

For example, it is possible to press Ctrl when focused outside of VS Code, then bring focus (via mouse) to VS Code, and then press S and that should be handled as Ctrl+S. The same can happen if focus is moved out of VS Code when a modifier is pressed. Or, sometimes, people use remote desktoping software or other keyboard intercepting software which cause similarly, for events to be dropped.

From my limited Windows C++ programming from more than a decade ago, I believe the recommended way was to query if a key is pressed, rather than tracking that by yourself. There is even GetAsyncKeyState for avoiding unprocessed messages in the event queue. From https://msdn.microsoft.com/en-us/library/windows/desktop/gg153546(v=vs.85).aspx :

Anyways, the problem, IMHO, is that:

• either the w3c spec is broken (or too limited)
• or Chromium implements the spec incorrectly.

[amcsi]

Alright, I see. Thanks for putting in the effort to write all this down though!

I can see that because of window focus change issues you definitely cannot rely on mousedown, and if Chromium truly makes it impossible to detect right alt specifically in the keypress event, then unless you made your own Chromium fork, this will be impossible. If that's something that you don't do here, then yes I find it unrealistic that this would ever get fixed here.

I rest my case.

[alexdima]

Thank you, I really appreciated the discussion. If you have sufficient energy, please go ahead and bring it up at https://bugs.chromium.org/p/chromium/issues/list . I think being able to distinguish Ctrl+Alt+ from AltGr+ is something any number of web applications would want to do (including the Monaco Editor) and it would only improve the web ecosystem.

[kwinz]

Using US-Int keyboard layout. AltGr+S should make a German ß character. Instead I get the "run task" menu jumping at me. Very annoying. Appreciate not handling AltGr (right alt) the same as ctrl + alt

[kwinz]

https://stackoverflow.com/a/39412714/643011
In my test this code snipped differentiates reliably between AltGr and Ctrl + Alt.
Tested in Chrome 67 under Windows 10 both with physical and on-screen keyboard.
Please use this code?

[amcsi]

Indeed that works in my Chrome as well

[iphigenie]

just nudging on this one as I have just installed on a clean machine and having to go through the list of bindings to find all the ones which override accents is an unnecessary pain.

[alexdima]

This has actually changed in Chromium, so AltGr+ no longer equivalates to Ctrl+Alt+. See #68003