Change:
I am not sure what causes it - it seems to happen intermittently. It is fixed if I change to a different app then come back to VSCode. REPRO: a python script that will raise an unhandled exception (I did it in WSL: Ubuntu) the exception is raised, press Backspace inside the text editor. It often will do nothing. the red square Stop icon to end debugging. in the text editor and try Backspace again. If it failed before, it will fail now 100% of the time until you select a different application in Windows and return to VSCode. [2022-05-03 17:01:11.112] [renderer1] [info] [KeybindingService]: / Received keydown event - modifiers: [], code: Backspace, keyCode: 8, key: Backspace [2022-05-03 17:01:11.112] [renderer1] [info] [KeybindingService]: | Converted keydown event - modifiers: [], code: Backspace, keyCode: 1 ('Backspace') [2022-05-03 17:01:11.113] [renderer1] [info] [KeybindingService]: | Resolving Backspace [2022-05-03 17:01:11.113] [renderer1] [info] [KeybindingService]:  From 1 keybinding entries, no when clauses matched the context. <html<body<!--StartFragment--Extension Version -- -- remote-containers 0.231.6 remote-ssh 0.78.0 remote-ssh-edit 0.80.0 remote-wsl 0.66.2 vscode-remote-extensionpack 0.21.0 python 2022.4.1 vscode-pylance 2022.4.3 <!--EndFragment--</body</htmlvsliv368cf: vsreu685: python383: vspor879: vspor708: vspor363: pythonvspyl392: pythontb: pythonvspyt551cf: pythonptprofiler: vshan820: vstes263: vscoreces: pythondataviewer: vscod805cf: pythonvspyt200: binariesv615: bridge0708: bridge0723: vsaa593cf: vsc1dst: pythonvs932: wslgetstarted: pythonvsnew555: vscscmwlcmt: cppdebugcf:
Normally, Backspace dispatching would look like this: The only context key it has is . So it looks like the editor does not think that it has focus. When you mention that you click the stop button and then focus via a mouse click in the editor, and Backspace still doesn't work, this makes me think that the entire VS Code window does not realize that it has focus. You mention that this reproduces when debugging a script which throws. Is the VS Code window becoming "auto-focused" or blinking in the taskbar or something unusual like that when the problem appears?
No blinking, and VSCode has focus in Windows. Below is a screenshot of when it is actively happening. This time I noticed that it did not accept directional arrow input, but did accept letter keystrokes. As in, a + leftarrow + b + c + backspace would produce 'abc' at the location of the cursor, instead of 'ba'. It seems that the keys that are or are not accepted are consistent. Directional arrows and backspace always break and letter keys always work when the issue occurs. My hunch is that something in the KeybindingService is intercepting and consuming "special" keys. The intermittent nature of this smells very much like a race condition. I noticed that the issue does not occur on my older computer ever. The computer this happens on is very new and has 128GB RAM, a 2TB M.2 drive, and a brand new Intel processor. It's possible that during testing and for 99% of users, their computers do not trigger the race, but my computer is CPU fast enough or storage fast enough to make the race relevant. Is the debugger on its own thread? ! It may be that the issue is that I have two VSCode windows open at the same time. The second window is for my remote CentOS machine. Below is a screenshot of the un-focused CentOS VSCode window at the time of repro, which has an active error box because my VPN connection timed out. Seems like a stretch but maybe this is related in some roundabout way. !
This is consistent with the workbench not realising it has focus. This manifests itself as being false, which means that all keystrokes will not get a call, but since the focus is actually in the text gets produced. Yes, I think this is very relevant. Normally, this dialog box should steal your focus and be revealed. I think that perhaps in this case the dialog box manages to only partially steal the focus. Do you have any ideas? It looks like the second window is showing a native dialog and that one fails to steal focus correctly.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This would be a side effect of the occlusion tracker on windows, we have had similar reports of the workbench process being incorrectly suspended during debugging can you try launching the application with and see if the issue repros ?
That fixes it

Discussion:
} }); <ins> /* Following features are disabled from the runtime. * `CalculateNativeWinOcclusion` - Disable native window occlusion tracker, *	Refs https://groups.google.com/a/chromium.org/g/embedder-dev/c/ZF3uHHyWLKw/m/VDN2hDXMAAAJ */ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); </ins> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {