Change:
Type: <bBug</bctrl+shift+e to bring focus to the explorer window the first letter of a file, e.g "p". Expected behaviour: focus moves to the next item starting with the character p, if one exists Actual: nothing happens, even when a file like exists. This broke pretty recently, sometime within the last week. VS Code version: Code - Insiders 1.78.0-insider (, 2023-04-07T05:20:50.322Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (31)</summaryExtensionVersion ------ astro-vscode0.28.2 vscode-eslint2.4.0 dendron0.119.0 dendron-markdown-preview-enhanced0.10.57 dendron-markdown-shortcuts0.12.1 dendron-paste-image1.1.1 dendron-snippet-maker0.1.6 gitlens13.5.0 prettier-vscode9.10.4 rest-client0.25.1 rainbow-csv3.6.0 isort2022.8.0 python2023.6.0 vscode-pylance2023.4.10 jupyter-keymap1.1.0 remote-containers0.289.0 remote-ssh0.98.0 remote-ssh-edit0.84.0 remote-wsl0.78.0 vscode-remote-extensionpack0.24.0 remote-explorer0.4.0 remote-server1.0.0 vsliveshare1.0.5834 vsliveshare-audio0.1.93 vsliveshare-pack0.4.0 vscode-versionlens1.5.0 rust-analyzer0.4.1469 svelte-vscode107.3.0 tauri-vscode0.2.6 shellcheck0.31.1 vscode-mermaid-editor0.18.1 </details<!-- generated by issue reporter --
Even going back over a week it seems only the first key down used to work to focus a file and now it doesn't. I don't see any builds which each letter press would hop. Do you have an example? I think maybe this has something to do with taking over
I don't know what the term is but it used to do incremental navigation. For example, if I had both and in the same directory, typing "p" then "y" consecutively moves focus to I'm using it with the NVDA screen reader, so I'm not sure if there's behavioural differences if VS Code detects that a screen reader is running. /CC
I could reproduce this with all extensions disabled.
fyi
can you take a look?
I'm trying to find the root cause of this and think it might be a regression from the new find widget in 1.70.0 There are two bugs here the first letter of a file name in the explorer doesn't focus it. This regressed sometime between 1.77.0 and 1.78.0. I haven't narrowed down the bad commit yet. issue described which is with the introduction of the find widget no longer exists as a setting. So you cannot do this focus hopping by typing the file name. This worked in 1.69.0 before the widget was introduced and can confirm it no longer works in 1.70.0
weirdly, when I build OSS from the 1.78.0 tag and try first-letter navigation on the explorer tree of the folder I open, it works. But when I repeat the test with the published 1.78.0 it doesn't. To rule out settings differences I pointed both of them at a fresh user-data-dir when launching. Likewise when I use Insiders the navigation doesn't work, but if I build OSS from main it does work. I am on Windows x64.
Yeah it's weird, I'm still investigating here because there is quite a few reports. By bisecting built bits I've narrowed it down to the following commit range to me it seems like the keybinding work might be to blame, but I'm not confident yet.
Confirmed regression caused by
Reopening to discuss for candidate process. Fix will be in tomorrow's insiders.
I think we should take it as a candidate, but I think softDispatch returning null or NoMatchingKb is confusing. Here is another place where I think we do the wrong thing now
Likely related on Stack Overflow:
I agree. I will refactor to not return a null at all. For now, I made a small fix to possibly include in the recovery release - Also, thank you for investigation! :-)
How to verify this is fixed: Focus on the file explorer, pressing a key should shift the focus to a file that starts with that key. For example, focusing on file explorer and pressing should move the focus to the first file that starts with .
Confirmed also that you can type for example "co" to get to core. Looks like both cases are fixed. Thanks.

Discussion:
} inMultiChord = false; <del> return !result; </del> <ins> return result === null || result.kind === ResultKind.NoMatchingKb; </ins> }; }