Change:
} if (nextVisibleFrame) { <del> debugService.focusStackFrame(nextVisibleFrame); </del> <ins> debugService.focusStackFrame(nextVisibleFrame, undefined, undefined, { preserveFocus: false }); </ins> } } }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: I have to have the MS Python extensions installed at a minimum to be able to launch the debugger, but disabling all other extensions, yes this issue still occurs. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.86.0-insider (Commit ) OS Version: Windows 11 (Connected to WSL via Arch Linux) I try to avoid using the mouse if at all possible. When using the aforementioned commands to navigate the call stack via the keyboard, I would ideally have my focus placed in the editor window where the new call stack location is, ready to navigate and make edits, but instead, my focus is placed in some kind of limbo. I can sometimes press to shift my focus to the editor, but then comes a secondary issue: when I try to use the arrow keys to move my cursor around (attempting to type text/pressing Escape doesn't help either), I am in some kind of locked state where I can't navigate or type even though my focus is on the editor (my cursor shows up, showing me that I am focused). This happens even when I use the to ensure that I am focused on the editor. If I shift focus to some other panel and then back to the editor, I am dropped out of this locked state. This issue seems to happen especially when switching to the next item in the stack has moved me into a new file; most of these issues don't happen when moving locations within the same file.

The text where the call occurred is also selected by default when moving up/down the stack, which I find to be slightly annoying since it is easily deleted on accident, and I'd prefer to just have my cursor placed at the start or end of that selection and have no text selected at all, but I can understand this choice. To clarify, expected behavior would be to just ensure that my editor is focused and ready to type right after the call stack switch occurs. I've only tried this using Python/debugpy, but I can't imagine that this has anything to do with the language/debugger used. Steps to Reproduce: a project with multiple files a breakpoint somewhere that will cause a few items to be to the call stack debugger (either by command palette or create keyboard shortcut) to navigate Up/Down the call stack (especially from one file to another) to find out where your focus currently is inside the window to shift focus back to the editor to type/navigate inside the editor
While for I still get the bad behavior for and and feel like those commands should have a similar change. When I run focus is lost from the editor.
Agreed