When resuming execution in the debugger, the debugged app should be given the focus

[tristanlabelle]

Is your feature request related to a problem? Please describe.
When hitting a breakpoint and resuming execution, it's useful to show the debugged app again. Xcode and big Visual Studio do this.

Describe the solution you'd like
When resuming execution, the debugger should find the main window associated with the process and bring it to the front.

Describe alternatives you've considered
Alt+tabbing back to the app.

Additional context
Unknown if this would need to be in the DAP or if the Swift extension has enough info to do it itself. It does feel like more of an editor/UI feature than DAP functionality. This would be OS-specific logic.

[adam-fowler]

Not sure I have control over this. It might be something you need to add an issue to the VSCode repo. Have you also checked the settings to see if there is one related to this?

[tristanlabelle]

There's no setting I found for this in VS Code, and I saw the dotnet/C# debugger doesn't implement this either.

I assumed this feature would be implementable in the Swift extension, because the DAP itself shouldn't be involved in presentation concerns and this is specific to the debugger type since it might not apply to a webpage. The Swift extension is the next layer in the stack that could have hooks to query the debugged process ID, find the Window and show it.

If you have more background and believe this is rather a missing VS Code feature, I can also file an issue there.

[adam-fowler]

You are right it has nothing to do with the DAP and is a UI thing. Unfortunately I don't think VSCode provides a hook into when continue is pressed. The suggestion is generic enough to be applicable to all debuggers so an issue on microsoft/vscode seems like a good idea.

[tristanlabelle]

I filed the bug upstream, and while thinking about it, there would be enough extensibility already for the Swift extension to use DebugSession.customRequest send a custom DAP request to the swift-lldb adapter to flip a boolean "Show app on resume" flag, at which point swift-lldb could implement this functionality and give the app focus upon receiving "continue" requests, having received a green light to do presentation-related things. What do you think?

[adam-fowler]

Sorry I misunderstood what you were trying to do here, you want the debugged app to regain focus.

I don't see the need for a custom request though, unless you want to make this configurable. The lldb-vscode DAP will receive the resume messages already, so it can control application focus when it receives that.

lldb-vscode is part of the LLVM libraries, it'd need to be implemented there. Unless you want to use a custom message and have it configurable I don't see what the extension needs to do.

Out of interest do you know what CodeLLDB does?

[tristanlabelle]

Sorry I misunderstood what you were trying to do here, you want the debugged app to regain focus.
Correct!

I was thinking of making it configurable because this is a presentation-level feature and not all debugging scenarios would require this (for example some automated debugging tool wouldn't).

Reading through, CodeLLDB just forwards to LLDB and eventually calls Process::PrivateResume, which has a set of pre-resume listeners that could be useful for this.

I'll file the issue on LLDB then.

[tristanlabelle]

Looking into this further, the Swift extension could already implement this using a DebugAdapterTracker:

• Use onDidSendMessage to listen to the Process event and store the systemProcessId.
• Use onWillReceiveMessage to listen for continue messages sent by VS Code, and perform platform-specific logic to find the the main window of the target process and give it the focus.

I think this would be preferable to implementing it in the DAP since it is a presentation-level feature.

[adam-fowler]

Yes you are right I could catch the continue event in a DebugAdapterTracker. I already use one of these to catch log messages.

I have no idea what the platform specific code to bring an application to the foreground would be. A quick search found this https://github.com/sentialx/node-window-manager. But it says Linux support is WIP and it hasn't had an update in 4 years.