keyboard shortcuts do not work for correct languaga although correct language active in gnome session

[bit15]

Issue Type: Bug

prior knowledge of important settings of environment:

• used system: ubuntu 20.04 => DE Gnome version before 40 (3.36)
• although I am german, alle settings in us english (for currency irish format to have euro as default currency) => first keyboard us, but second is de (german)
• visual code also en for having keyboard shortcuts in en
• in gnome session en is active (naturally)

e.g.: comment line is ctrl+/ and this works in this case

but if I change the place of the german keyboard in gnome to place one, then suddenly for commenting I have to use ctrl+& (ctrl+shift+7), although en is active yet => visual code looks for shortcuts only which keyboard is set on first position in gnome, but not which keyboard is active currently!

VS Code version: Code 1.61.2 (6cba118, 2021-10-19T14:58:13.605Z)
OS version: Linux x64 5.11.0-38-generic snap
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 2000)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	1, 1, 1
Memory (System)	23.35GB (11.23GB free)
Process Argv	--no-sandbox --force-user-env --unity-launch --crash-reporter-id e1dddc85-d981-4ecd-a0ec-b68962e63e5d
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

Extensions (2)

Extension	Author (truncated)	Version
Bookmarks	ale	13.2.2
cpptools	ms-	1.7.1

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
vsccppwtct:30382698
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt3:30385195
dockerwalkthru:30377721
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedc:30364665
pythonvspyt187:30373474
vsqsis200:30386379
vsaa593:30376534
vssld246:30386377
vscrecpromptt3:30387013

[alexdima]

@bit15 Last week, we have pushed two important fixes to the keyboard layout support under Linux, we basically fixed #23690 and #24166 . Could you please try our insiders build and check if the selected keyboard layout is now detected correctly?

[bit15]

@bit15 Last week, we have pushed two important fixes to the keyboard layout support under Linux, we basically fixed #23690 and #24166 . Could you please try our insiders build and check if the selected keyboard layout is now detected correctly?

@alexdima: Sorry I am a noob in things like this insider builds. Because of this little GUI change in gnome I had to solve this strange problem for continuing to work on my \university-c++-opengl'-project (and alongside of this I wanted to know what the reason for this problem is). Therefore it would be not that good if I have to break my work a long time. As I have seen, there is in snap store a insiders build. Without risk I can install this build alongside and try, if this workaround works. And later on I am able to use the official stable build again? If I am right, there are as separate builds visual code and visual code insiders and do not conflict each other ... besides in workspace perhaps, I should backup when trying insiders build?

Other question for my knowledge, as I do not have knowledge in gnome development: This app gets information from gnome API, or? If yes, can it ask gnome which keyboard layout is active at the moment? And if this possible, too, the app can know if focused, or? And if all possible as I hope, then this app can verify if keyboard layout changed and change it accordingly if needed? Or costs the last point to much I/O-time?

[alexdima]

@bit15 Yes, VS Code Insiders can be installed side-by-side with VS Code Stable. VS Code Insiders is updated every night, and VS Code Stable is typically updated once per month. You can simply wait, the fixes will appear in the stable channel in the next couple of weeks. If you want to benefit from the fixes now, you will have to install VS Code Insiders.

The fixes I mentioned are about reading the selected keyboard layout and reacting to the selected keyboard layout being changed. This is implemented in C++, in a native node module that we ship with VS Code, using X11 APIs.

[bit15]

used:
Version: 1.62.0-insider
Commit: dc1a669
Date: 2021-10-26T08:48:02.966Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.11.0-38-generic snap

test result:

• start code (insiders) with german (de) keyboard first in gnome (no matter if de or en active): toggle line comment does not work ... menu says, toggle line comment has no keyboard shortcut. Then (while de active) in keyboard shortcuts I add ctrl+shift+7 (in shift+7 is the slash on german keyboard layouts). As assumed, this works now. But astonishingly ctrl+'-' (in en layout ctrl+/) works, too. If I switch layout without or with restarting snap, it keeps the same.
• then I deleted again this keyboard shortcut (sadly I do not know how to remove all additionally stored settings of snap package, not only the snap package) to get back again somehow to the first state
• now app restarted with en layout defined at first and en active ... now suddenly toggle line comment has a keyboard shortcut (as expected ctrl+/). When switching to de (with and without restarting code insiders), ctrl+/ (in de ctrl+'-') keeps working, but ctrl+shift+7 does not work, although expected if using de layout

I hope my given info helps, as for me this seems a bit chaotic.

PS: what is the way to remove settings of a snap package? 'sudo snap remove code-insiders --purge' seemed not to help, as reinstall seemed to restore old settings

[bit15]

Sad, I deleted $home/snaps/code-insiders and $home/.code-insiders but start of snap code-insiders brings the opened files back again. What do I have to delete to ensure, the snap package is native again without any settings made by user?

[bit15]

Yeah, I seem to have found where the user config data is stored. The folders '$home/snaps/code-insiders' and '$home/.code-insiders' seem not to have the user config. The user config seems to be in '$home/.config/code - insiders' (with spaces in name?!?!?). For what are the first two mentioned folders?

Now a clean test without trying to set keyboard shortcuts (used method: toggle line comment):

• start with de layout on position 1 & active: ctrl+shift+7 works, nothing else (menu tells this shortcut exists)
• switching to en layout w/o restarting app: ctrl+/ like ctrl+shift+7 do not work (menu tells, shortcut does not exist)
• restart app: same states as earlier on (with de or en layout active the same behaviors)
• restart app now with en layout on position 1 and en active: now ctrl+/ works and nothing else
• switch active layout to de: now ctrl+- (in en layout ctrl+/) AND ctrl+shift+7 (as expected, because shift+7 is / in de keyboard layout) works ... both work!
• now restart app: the same behavior like earlier on starting app with en on pos 1 & en active (or later on switched to de)

As noticed in earlier post, I have to keep en layout on pos 1 to be being able to use the en keyboard shortcuts (the active layouts seem not to be observed by the app).

Here the metadata if app changed while trzing to remove the user data of this snap:
Version: 1.62.0-insider
Commit: 0f7f6e3
Date: 2021-10-27T05:16:22.862Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.11.0-38-generic snap

[alexdima]

@bit15 Thank you for trying out Insiders and following up. You have done many tests and I thank you for that, and they all hint towards us not recognizing the current active keyboard layout, but I would like to please ask you to do the following to confirm that is the case:

0. preparation

• open VS Code Insiders
• run F1 > Preferences: Open Keyboard Shortcuts (JSON)
• comment all your custom keybindings from keybindings.json
• run F1 > Preferences: Open Settings (JSON)
• configure "keyboard.dispatch": "code" (this is the default, but I would like to make sure you didn't change it to "keyCode" in earlier troubleshooting efforts)
• disable all installed extensions (there should be none because this is insiders)
• close VS Code Insiders

1. let me know the output of setxkbmap -query

2. test if vscode reads the active keyboard layout correctly

• close all instances of vscode-insiders
• if the output of setxkbmap -query is us,de,... (with the us keyboard layout first), change your active keyboard layout to de. If the output is de,us,.., change your active keyboard layout to us. In other words, chose the second one as the active keyboard layout. Let me know which one you select.
• open VS Code Insiders
• open a new untitled file
• run F1 > Developer: Inspect Key Mappings
• does the printed layout info match your current active keyboard layout?
• in any case, save that to a file .txt and attach it.

3. test if vscode reacts to changing active keyboard layout

• (continue in the VS Code Insiders instance from above)
• close all files
• open a new untitled file
• with VS Code Insiders running, change the active keyboard layout from the "second" to the "first"
• run F1 > Developer: Inspect Key Mappings
• does the printed layout info match your current active keyboard layout?
• in any case, save that to a file .txt and attach it.

[bit15]

initial: keyboard layout en (macintosh) set on pos 1, also active

point 0:
keybindings.json is 'empty' {contains only '// Place your key bindings in this file to override the defaults
[
]')
settings.json is 'empty' {contains only '{
}') ... no "keyboard.dispatch": "code" or similar available ... is this ok?

No extensions naturally installed (only on first try I tried 'real world'-test, but removing '$home/.config/code - insiders' seemed to be sufficient to remove the only c++ from microsoft extension)

point 1:
output of 'setxkbmap -query' when en on pos 1:
'rules: evdev
model: pc105
layout: us,de,us
variant: mac,mac,' (mac version on thinkpad to get altgr+n for being able to write easily in spanish the letter 'ñ')

output when de on pos 1:
'rules: evdev
model: pc105
layout: de,us,us
variant: mac,mac,'

point 2:
For the two different printed layouts have each other a matching key map told by insiders app. It does not matter which keyboard layout is active in gnome session. Relevant is only the 'position:' told by 'setxkbmap -query'.

Layout infos of keyboards - first en active de - second de active en.txt
(attention: this file contains two outputs of two tests - first test: en first & active de - second test: de first & en active ... sorry, description in file a bit confusing)

point 3:
Layout infos of keyboards - first en active de - second de active en - point 3.txt
(attention: this file contains two outputs of two tests - first test: en first & de active switched to en - second test: de first & en active switched to de ... sorry, description in file a bit confusing)

Hopefully my output helps to identify why the active keyboard layout seems to be ignored and only the position of the keyboard layouts seems to be relevant.

[bit15]

updated description in files and better file names:

Layout infos of keyboards - first test en first active de - second test first de active en - point 2.txt

Layout infos of keyboards - first test en first active de - second test first de active en - in both tests switch active layout back - point 3.txt

[alexdima]

@bit15 Thank you for the extra information. I can now also reproduce. The steps are:

• configure input sources like this with German (Macintosh):
  
• switch the active keyboard layout to de from the top bar
• run F1 > Developer: Inspect Key Mappings

Some of the problems I've noticed:

	"KeyY": {
		"value": "y",
		"withShift": "Z",
		"withAltGr": "←",
		"withShiftAltGr": "¥",
		"withLevel5": "z",
		"withLevel3Level5": "←"
	},
	"Slash": {
		"value": "/",
		"withShift": "_",
		"withAltGr": "–",
		"withShiftAltGr": "—",
		"withLevel5": "-",
		"withLevel3Level5": "–"
	},

This is not true, as pressing KeyY produces z, not y. On the other hand, pressing Shift+KeyY does produce Z, which is correct.

Similarly, pressing Slash produces -, not /. On the other hand, pressing Shift+Slah does produce _, which is correct.

So I believe there is something off about the value we use for the modifier state (in the no modifier case) in our C++ module.

---

As a workaround, please try to use "keyboard.dispatch": "keyCode".

[bit15]

I am glad I could help to find the location of the bug. Thank you for fixing the bug.

@alexdima:
Edited because written misunderstoodale:
About workaround: when (en on pos 1 & de active or de on pos 1 & de active) => mentioned combination in menu for toggle commenting line does not work (in version not for insiders) ... the workaround does not fix this for de layout - it helps only in the case which is more important for me, that coding with en layout is possible w/o hassles, right?

Perhaps interesting aspect: in opengl+'C++-' I can not move object in the opengl context with cursor, when de on pos 1 => I have to keep en on pos 1 ... in older ubuntus this worked flawlessly ... bug introduced in new ubuntu perhaps since 20.04? could this be a bug in GLFW or in gnu c library or in X11?