VSCode intermittently stops accepting input

[ColinBundschu]

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:

1. Run a python script that will raise an unhandled exception (I did it in WSL: Ubuntu)
2. While the exception is raised, press Backspace inside the text editor. It often will do nothing.
3. Click the red square Stop icon to end debugging.
4. Click 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.

Extension	Author (truncated)	Version
remote-containers	ms-	0.231.6
remote-ssh	ms-	0.78.0
remote-ssh-edit	ms-	0.80.0
remote-wsl	ms-	0.66.2
vscode-remote-extensionpack	ms-	0.21.0
python	ms-	2022.4.1
vscode-pylance	ms-	2022.4.3

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebugcf:30475217

[alexdima]

Normally, Backspace dispatching would look like this:

[KeybindingService]: / Received  keydown event - modifiers: [], code: Backspace, keyCode: 8, key: Backspace
[KeybindingService]: | Converted keydown event - modifiers: [], code: Backspace, keyCode: 1 ('Backspace')
[KeybindingService]: | Resolving [Backspace]
[KeybindingService]: \ From 1 keybinding entries, matched deleteLeft, when: textInputFocus, source: built-in.

The only context key it has is textInputFocus. 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?

[ColinBundschu]

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.

[alexdima]

Directional arrows and backspace always break and letter keys always work when the issue occurs.

This is consistent with the workbench not realising it has focus. This manifests itself as textInputFocus being false, which means that all keystrokes will not get a .preventDefault() call, but since the focus is actually in the <textarea> text gets produced.

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.

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.

@deepak1556 Do you have any ideas? It looks like the second window is showing a native dialog and that one fails to steal focus correctly.

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[deepak1556]

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 #123257

@ColinBundschu can you try launching the application with --disable-features=CalculateNativeWinOcclusion and see if the issue repros ?

[ColinBundschu]

That fixes it