(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Chorded snippets (snippets activated by pressing keys simultaneously) (#46487)
• Emit first key chord when timeout or wrong second key chord (#15550)
• Add suggested completions for key chords (#3969)
• keybindings using [ContextMenu] key sometimes ALSO trigger UI context menu (#47403)

As a temporary work-around you can disable highlight/filtering in the tree. Change the setting Workbench > List: Keyboard Navigation to simple or in json:

"workbench.list.keyboardNavigation": "simple"

@pedro-pedrosa I can only reproduce if the workbench.list.keyboardNavigation is set to simple. Do you by any chance have that configuration?

Currently set to highlight.

"workbench.list.keyboardNavigation": "highlight"

Anything else you'd like me to check?

If I change it to simple it both triggers the chord and selects a file. If I change it to filter, it doesn't trigger the chord and starts filtering the file tree, same behaviour as highlight.

I'm able to reproduce this issue in latest Insiders build.

1. Click on any file in Explorer
2. Press Ctrl + K - status bar shows (Ctrl + K) was pressed waiting for second key of chord...
3. Press any key - it is added to highlight, status bar still shows (Ctrl + K) was pressed waiting for second key of chord...

I have "workbench.list.keyboardNavigation": "highlight" in settings.

If I switch it to "simple" than I see next behavior:

1. Press Ctrl + K - status bar shows (Ctrl + K) was pressed waiting for second key of chord...
2. Press s - all edited files saved, status bar is cleared and file/folder starting with s is focused

VS Code version: Code - Insiders 1.32.0-insider (1c50a87, 2019-02-08T06:16:17.233Z)
OS version: Windows_NT x64 10.0.17763

I've noticed one more thing:

1. If i focus terminal window, and press ⌘K, ⌘S - nothing happens, even if i just press ⌘K i don't see the message ⌘K was pressed waiting for second key of chord..., but if i press ⌘R, then i see the message i mentioned above, but ⌘R, Shift+R doesn't work.
2. if i focus editor window itself, then all keybindings do work.
3. if i focus explorer window, then ⌘K, ⌘S work, but ⌘R, Shift+R doesn't work, it instead highlighting the root folder:

Just checked my keybindings:

As you can see, the When column is empty, so it means these keybindings should fire independent of focused area, e.g. text editor, terminal, explorer. Clearly a bug in 1.31 version.

I can confirm. Steps:

• define new keybinding, e.g.:

{
    "key": "ctrl+k s",
    "command": "actions.find"
}

• focus the explorer
• press ctrl+k
• the first part of the chord is entered
• press s
• the tree begins to highlight 's'.

The workaround provided by kieferrm works for me, which is to define in settings.json:

"workbench.list.keyboardNavigation": "simple"

As @pedro-pedrosa and @IllusionMH note, pressing s for example will trigger the chord and move the focus in the explorer to the first element with s.

@heihachi88 Please create a separate issue regarding the terminal. For the explorer, please try the workaround "workbench.list.keyboardNavigation": "simple"

"workbench.list.keyboardNavigation": "simple - it's just a workaround? Things won't change in the future regards this setting?

Disabling features is not a workaround.

I can repro this on Windows, but not on macOS and Linux.

@alexandrudima Check out what I get with Ctrl K.

Ctrl-F17?! 🤔 Investigating...

@alexandrudima Found the issue. I was passing a raw KeyboardEvent to softDispatch which was resolving to that ctrl+F17 keypress. As soon as I wrapped it around StandardKeyboardEvent, I got the correct behavior:

I'll close this with that fix... but you might want to look into it.

@joaomoreno That is crazy, I didn't realize TS would find those to be compatible... Thanks for the heads up. I've pushed 2ff5d6b which makes it more obvious and found another bad usage :/ 2ff5d6b#diff-2203e613237f08bd954dd0a758dfffb4R360