Cannot navigate the file using keyboard arrows

[InKiev]

• VSCode Version: Code - Insiders 1.11.0-insider (27d1dbd, 2017-03-02T11:11:16.467Z)
• OS Version: Windows_NT ia32 10.0.10586
• Extensions:

Extension	Author	Version
one-monokai	azemoh	0.2.4
path-intellisense	christian-kohler	1.2.0
Theme-monokai-best	gerane	0.0.2
tsimporter	pmneo	1.2.13
vscode-icons	robertohuertasm	7.3.0
todotasks	sandy081	0.4.0

---

Steps to Reproduce:

1. Open a file
2. Indicator is not in the correct position and is not possible to navigate the file using the keyboard's arrows keys

[AaronFriel]

Same issue, no extensions in common.

$ code-insiders --version
1.11.0-insider
c995ecf2e94a00aa7eda81ed842e787b999e83ae
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.10
DISTRIB_CODENAME=yakkety
DISTRIB_DESCRIPTION="Ubuntu 16.10"
$ uname -a
Linux ubuntudev 4.8.0-44-generic #47-Ubuntu SMP Wed Mar 22 14:27:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[AaronFriel]

When I try to set a keymap for "cursorDown", this is what I see when I press the down arrow:

I pressed the down arrow, not enter.

When I press left arrow, right arrow, or up arrow, I see "unknown".

[AaronFriel]

I bisected the versions available:

1.11.0-1490594535 BAD
1.11.0-1490347334 BAD
1.11.0-1490252542 GOOD
1.11.0-1490166151 GOOD
1.11.0-1489993365
1.11.0-1489737822
1.11.0-1489649811 GOOD
1.11.0-1489389218
1.11.0-1489129388
1.11.0-1489044044
1.11.0-1488956710
1.11.0-1488871392
1.11.0-1488784809 GOOD
1.11.0-1488524610
1.11.0-1488439219
1.11.0-1488265408
1.10.0-1488204485
1.10.0-1487968147
1.10.0-1487921388
1.10.0-1487833419
1.10.0-1487747028
1.10.0-1487661178
1.10.0-1487338510
1.10.0-1487314590
1.10.0-1487229188
1.10.0-1487199085 GOOD

[alexdima]

@AaronFriel

What keyboard layout do you use? Can you please run F1 > Developer: Inspect Key Mappings, save the output to a file and attach it here.

Is there any output when running code-insiders from the command line in the terminal you launch it from?

In today's insiders build, can you please try:

• Open the define keybindings widget (the one you are already using)
• Press down arrow
• Hover over the input field (this shows the raw values we get from the keydown event)
  
• The first three values for code, keyCode and key are the values coming in from the browser keydown event
• The other values are our interpretation of the keypress in the UI, user settings, kb dispatch tables, etc.

[AaronFriel]

I installed 1.11.0-1490775389 from the Ubuntu repository.

What keyboard layout do you use?

Layout info:
{
	"model": "pc105",
	"layout": "us",
	"variant": "",
	"options": "",
	"rules": "base"
}

Can you please run F1 > Developer: Inspect Key Mappings, save the output to a file and attach it here.

Keymappings.txt

Is there any output when running code-insiders from the command line in the terminal you launch it from?

None, should I run it with a command line argument to see some output?

Open the define keybindings widget (the one you are already using)
Press down arrow
Hover over the input field (this shows the raw values we get from the keydown event)
The first three values for code, keyCode and key are the values coming in from the browser keydown event
The other values are our interpretation of the keypress in the UI, user settings, kb dispatch tables, etc.

Down arrow:

Left arrow:

Up arrow:

Right arrow:

The initial enter appears to be stuck as the chord if I press it first, but I often get just unknown, same values though on hover.

[AaronFriel]

In case it's relevant:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[alexdima]

@AaronFriel

Thank you very much for following through with this information.

From the Keymappings.txt file, it appears that our C++ node module reads the OS keyboard layout correctly (i.e. what scan code + modifier combo produces what character).

From us printing unknown, it also appears that our code interpretation logic is correct, i.e. we have no clue what to do with the keys Covert, Lang3 and NonConvert.

The problem is that, under your system, Electron/Chromium completely messes up keydown.code at runtime, which I thought is the only trustable value (you can see my analysis in #17521).

Moreover, it looks like keydown.keyCode and keydown.key are correct which is a somewhat good thing. It means we can look into a workaround.

Action for me:

I will add a setting (off by default) which will force keyboard dispatching to use keydown.keyCode. That should serve as a workaround for you or anyone else running into this insane issue.

Action for you:

Since the root cause of this issue appears to be in Electron/Chromium, could you please use Chromium and try the arrow keys at https://jsfiddle.net/v1gz5c5m/1/ . You could also compare the output with Firefox (the output should be the same, i.e. scan codes should match what you press ).

If Chromium prints good scan codes in the jsfiddle, it means that Chromium has already fixed this issue and once we adopt newer versions (we are now on version 53), we should at some point get the fix.

If Chromium prints crazy scan codes, then please consider creating an issue against them at https://bugs.chromium.org/p/chromium/issues/list

[alexdima]

"keyboard.dispatch": "keyCode" can be used to forcefully go to keyCode based dispatching.

[AaronFriel]

This is probably not good, right? My Chromium on Linux is also showing weird keycodes on arrow presses.

This is Google Chrome on Windows:

One last quirk of my environment: I am using X11 forwarding. Is that possibly what the issue is? I would guess not, because it's reading the appropriate "key" value, it's the "code" that's very strange. And my locale, keyboard configuration, and so on are identical between the Windows OS and the Ubuntu 16.10 VM.

[AaronFriel]

This appears to be a similar issue with Atom:

[1] https://discuss.atom.io/t/ctrl-arrow-key-sends-unrelated-combination-to-atom/36405/3
[2] electron/electron#8116

But it also looks to be slightly different, their issue seems to be that the code is incorrect when using modifiers. My arrow keys don't work when not using modifiers.

As with their articles, my X keyboard map appears correct:

$ setxkbmap -query
rules:      base
model:      pc105
layout:     us

Since my X11 remoting is working just fine, and old versions of Chromium work fine, I don't think it's related to me using X11 forwarding. The other bugs do not include it, and have the same symptoms. (Down arrow is NumpadEnter, other arrows are IME codes, apparently "Lang3" is for Hiragana?!)

[alexdima]

@AaronFriel Having the issue reproducing under Chromium is somewhat of a good thing. It means you are fully equipped to file a bug against https://bugs.chromium.org/p/chromium/issues/list

All that would be needed for you to prove it is a Chromium issue is to run the same test under Firefox and show that Firefox does the right thing. If you create an issue, please link to it here in the comments. Thanks!

P.S. starting with today's insiders you should be able to use "keyboard.dispatch": "keyCode" in user settings to workaround this quirk.

[roblourens]

Should "keyboard.dispatch": "keyCode" cause it to work the same as in 1.10? With that setting, I can't repro the issues that I see in 1.10, like #1492

[AaronFriel]

@alexandrudima Could you help me out by describing what a good bug report would look like? It would be very helpful!

[AaronFriel]

I am very confused! Firefox has the same issue?

But if I use the xev utility, I see the right codes?

KeyPress event, serial 29, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179649750, (429,410), root:(2511,555),
    state 0x0, keycode 104 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179649843, (429,410), root:(2511,555),
    state 0x0, keycode 104 (keysym 0xff54, Down), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650015, (429,410), root:(2511,555),
    state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650125, (429,410), root:(2511,555),
    state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650359, (429,410), root:(2511,555),
    state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650484, (429,410), root:(2511,555),
    state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650718, (429,410), root:(2511,555),
    state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x800001,
    root 0x2df, subw 0x0, time 179650812, (429,410), root:(2511,555),
    state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

I can even rebind arrows with xmodmap and those show up correctly in the "key" field, but not in the "code". For example, here's every arrow rebound to up:

Note that Chromium and Firefox agree:

• keyCode: 38 (up arrow)
• key: ArrowUp

But what on earth is code coming from?!

[alexdima]

@AaronFriel Even if both browsers show the same weird values for code, I still think this is an issue with their extraction of code, possibly a bug both browsers share...

I am no expert in this topic, but a quick search in Chromium's sources shows how they extract these values from an XEvent:

---

e.code:

https://cs.chromium.org/chromium/src/ui/events/keycodes/keyboard_code_conversion_x.cc?dr=C&l=882

DomCode CodeFromXEvent(const XEvent* xev) {
  int keycode = (xev->type == GenericEvent)
                    ? static_cast<XIDeviceEvent*>(xev->xcookie.data)->detail
                    : xev->xkey.keycode;
  return ui::KeycodeConverter::NativeKeycodeToDomCode(keycode);
}

---

e.key

https://cs.chromium.org/chromium/src/ui/events/keycodes/keyboard_code_conversion_x.cc?dr=C&l=905

DomKey GetDomKeyFromXEvent(const XEvent* xev) {
  XEvent xkeyevent = {0};
  XKeyEvent xkey;
  if (xev->type == GenericEvent) {
    // Convert the XI2 key event into a core key event so that we can
    // continue to use XLookupString() until crbug.com/367732 is complete.
    InitXKeyEventFromXIDeviceEvent(*xev, &xkeyevent);
    xkey = xkeyevent.xkey;
  } else {
    xkey = xev->xkey;
  }
  // There is no good way to check whether a key combination will print a
  // character on screen.
  // e.g. On Linux US keyboard with French layout, |XLookupString()|
  //        * Returns '?' for ctrl-shift-/
  //        * Returns '§' for shift-/
  //      According to spec the DomKey for ctrl-shift-/ should also be '§'.
  // The solution is to take out ctrl modifier directly, as according to XKB map
  // no keyboard combinations with ctrl key are mapped to printable character.
  // https://crbug.com/633838
  xkey.state &= ~ControlMask;
  KeySym keysym = XK_VoidSymbol;
  XLookupString(&xkey, NULL, 0, &keysym, NULL);
  base::char16 ch = GetUnicodeCharacterFromXKeySym(keysym);
  return XKeySymToDomKey(keysym, ch);
}

e.keyCode

https://cs.chromium.org/chromium/src/ui/events/keycodes/keyboard_code_conversion_x.cc?dr=C&l=494

// Get an ui::KeyboardCode from an X keyevent
KeyboardCode KeyboardCodeFromXKeyEvent(const XEvent* xev) {
  // Gets correct VKEY code from XEvent is performed as the following steps:
  // 1. Gets the keysym without modifier states.
  // 2. For [a-z] & [0-9] cases, returns the VKEY code accordingly.
  // 3. Find keysym in map0.
  // 4. If not found, fallback to find keysym + hardware_code in map1.
  // 5. If not found, fallback to find keysym + keysym_shift + hardware_code
  //    in map2.
  // 6. If not found, fallback to find keysym + keysym_shift + keysym_altgr +
  //    hardware_code in map3.
  // 7. If not found, fallback to find in KeyboardCodeFromXKeysym(), which
  //    mainly for non-letter keys.
  // 8. If not found, fallback to find with the hardware code in US layout.

  KeySym keysym = NoSymbol;
  XEvent xkeyevent = {0};
  if (xev->type == GenericEvent) {
    // Convert the XI2 key event into a core key event so that we can
    // continue to use XLookupString() until crbug.com/367732 is complete.
    InitXKeyEventFromXIDeviceEvent(*xev, &xkeyevent);
  } else {
    xkeyevent.xkey = xev->xkey;
  }
  KeyboardCode keycode = VKEY_UNKNOWN;
  XKeyEvent* xkey = &xkeyevent.xkey;

  // ....

}

I really have no idea what is really going on, but I do see a discrepancy in handling the xev->type == GenericEvent case. Then again, it might not mean anything. I simply suggest for you to open an issue and follow up with any additional information they might ask from you.

[alexdima]

@roblourens Thanks for trying to verify. On OSX, the 1.10 behaviour was more complicated than using keyCode. On OSX, in 1.10, there was some piece of code that would try to "normalize" e.keyCode. This fixed some issues for some keyboard layouts, but it possibly made DVORAK even worse. That piece of code has been removed since the move to dispatch on e.code. However, there was no such code on Linux, so I think one could reproduce a former linux issue by switching "keyboard.dispatch": "keyCode"

[AaronFriel]

@roblourens "keyboard.dispatch" patch works for me, as well.

I am still perplexed by what causes the weird keycode values.