debug focus automatically switches to newly created debug session

[weinand]

Steps:

• unpack and open attached Cluster.zip project in VS Code
• set breakpoint in test.js line 15
• start debugging by running the "Cluster" launch config
• after hitting breakpoint press Continue button on debug toolbar

Observe: a new debug session starts and the corresponding node in the CALL STACK gets selected. As a consequence the debug focus switches to the new session and the debug toolbar no longer shows the "Continue" button. In order to continue stepping, a stopped debug session must be selected in the CALL STACK view.
This happens for every new child process of the cluster...

A new debug session should never change the selected session in the CALL STACK view (at least if there is already a stopped debug session.

[isidorn]

I checked last two stables (1.58 and 1.57) and we were already behaving like this.
Whenever there is a new session it would steal focus, even if there is already a session that is stopped and focused.
I would prefer not to change this as part of endgame -> August. Especially since the js-debug sort of relies on this that the child session which comes after the parent session would take the focus away.

also fyi @connor4312 to get his thoughts

[connor4312]

Yea I think if a debug session is paused, focus should not be automatically moved away

[weinand]

If this is not a regression, I'm fine with not fixing this for July. But we should fix this at the beginning of the August cycle.

[gjsjohnmurray]

Maybe #121898 is related.

[isidorn]

I pushed a similar fix for #128400
However the problem with this issue is the following:

• once a user presses continue we do not know that the Session 1 will be stopped again in a couple of ms. I have basically mentioned this problem here When thread is no longer stopped the focus is not automatically passed to another thread #125144 (comment)

So the only way to solve this that I see is to auto focus only after a timeout. Which Visual Studio does not do.
Let me know your thoughts.

[baybal]

Given this is a very rare opportunity to catch people who work on VScode JS debugger, I have a small offtopic question

How does the debugger know the line number on which console.log was called, and how a wrapper for it can pass it along to the real console.log while preserving object inspectability, formatting, colours, etc?

It's important for logger packages like https://github.com/winstonjs/winston

[connor4312]

@baybal you can file issues here or on js-debug and I usually respond within 24h 😉 The debugger knows the line console.log is called on since the call stack reported by V8. The first non-skipped location in the stack will be shown, which you can adjust using skipFiles patterns.

[weinand]

@isidorn above you said:

once a user presses continue we do not know that the Session 1 will be stopped again in a couple of ms. I have basically mentioned this problem here #125144 (comment)

I do not understand how your statement is related to the issue at hand:

my ask was: A new debug session should never change the selected session in the CALL STACK view because the new session is running and there is nothing that needs to be shown by focusing on it. Only if the new session stops, we should focus on it.

So there is no other paused process/thread to which we can/should pass the focus (as was asked in #125144).

[weinand]

I cannot verify this.

Please see:

[isidorn]

The fix I did, did not cover the case when all sessions are siblings.

Before we would always focus on a new child session if the parent session was focused. This does not really make sense in general, and would only make sense for js-debug. I have removed this behaviour and this indeed fixes the issue.
So in theory now when a user starts a js-debug session which does not hit any breakpoints the parent session will remain focused until the child gets stopped. I think this makes sense in general.

I suggest to do this for the September milestone, since we have always behaved like this and to give some time to catch potential regressions. I have pushed a fix for this to main, if somebody would like to have this as part of the release please let me know and I can create a PR against the release branch.

fyi @roblourens

[weinand]

@isidorn this works now for my Cluster.zip sample.