When debug session has just one thread, render this thread inline with the session itself

[isidorn]

No description provided.

[isidorn]

To verify have a simple node program to debug.
Start debugging it and hit a breakpoint.
Create a new launch config which also debugs another simple node program.
Start debugging it and hit a breakpoint.

Verify that in the call stack view you can see both debug sessions and their call stack. However the threads are not shown.

[pavelfeldman]

Happy to see this moving along. A couple of comments from my side:

• Don't render expansion control when there are no children!
  All my sessions have single thread and as a result, they are all expandable, but due to inlining, they are all empty upon expansion.

• When there is only one top-level session, inline its children.
  As seen on the screenshot below, my launch configuration corresponds to a single 'root' session. Rendering that group "Web page 2" does not seem to be necessary.

• When the web page navigates between the URLs, its thread name changes. I'd be great to either allow session to be renamed or to render the thread name in the tree instead. I can force thread rename via removing and re-adding it back today.

[pavelfeldman]

One more:

• As I'm typing in console of a particular session, should a new session be created, it becomes active and steals the console from under me.

[pavelfeldman]

Another one:

• When my session has a child session and a thread, I still expect to see my only thread inlined. I.e. in my case session === thread. This does not seem to be the case today, session blank has a thread localhost5002 and a child session sw.js:

At the same time, my expectations are:

• localhost:5002 (session and thread)
  • sw.js (session and thread)
• serve.js [51030] (session and thread)

[isidorn]

@pavelfeldman thanks a lot for the great feedback. We usually prefer seperate new issues, but let's continue the discussion here and we can open new issues.

1. Expansion control when there are no children: currently we do this everywhere across VS Code (Explorer, Variables view, Watch Expression). If we were to change this we would have to fetch children even before the element gets expanded, just to know if he has any children or not. What we currently do is that the thread should not be shown as expandble if it is not stopped here. So the question for me is why the Thread in the model is marked as stopped when it is clearly running. I would need repro steps to investigate more here.
2. This makes sense, I have just tackled this via 72803aa Previously we would always show the session if we were once in a mulit session view (and you go back to one session). Though always saving space makes sense and I like this change. Please note that in the debug toolbar we will still show the dropdown such that the user is aware that there were multiple sessions in the past and that he is left with just one.
3. This should already be possible. Similar issue When name of thread is changed, the UI is not updated.  #18244. Please try to send a ThreadEvent and as a reason set new. VSCode will ask you for all the threads and you just return with the updated names. And we should handle it nicely here. Maybe we shuold just add a reason "update" just to make this more clear in the DAP @weinand
4. Similar issue here Multi-target debugging: Avoid automatic switching debug console focus #77836 Let's continue the discussion there
5. This makes sense. I have just tackled this via b8ec1d7

Thanks again for the feedback.

fyi @weinand

[isidorn]

4. Upon further investigation I have pushed 38aa476 which should tackle this issue in your case. We were auto focusing the newly created session even if it was not stopped which was wrong. So I changed that, we no longer switch focus when a new session is created. However our approach remains that if a breakpoint is hit we will automatically focus on the coresponding session. Please try it out and let me know how it behaves. I would be interested to hear your feedback on our auto focus behavior when there are multiple threads / sessions. Thanks

[weinand]

I've verified that this works as discussed with two instances of a simple long-running node program:

setInterval(() => {
	console.log("tick");
}, 1000);

@isidorn What I find a bit surprising is the following:

If there are no breakpoints set, starting one debug session does not show anything in the CALLSTACK view. This is only mildly surprising because VS Code always behaved like this for single-threaded programs.

Starting the second debug session results in two sessions:

Terminating the second session makes both items disappear which gives the wrong impression that both sessions have terminated. It would be more intuitive if we would not optimise in the n-> 1 transition and continue to show a single session. This is a strategy that we are already using in other places.

[isidorn]

@weinand agree that that one is a bit of a bad corner case and that users might think that both sessions are gone.
We can go back to the previous behavior (not optimising the n->1 transition).

We could also introduce a new heuristic instead: if a session is running (has no threads) show it in the call stack view always. That way we would also tackle the first surprising scenario.

@weinand @pavelfeldman let me know what you think and which approach you prefer.

[pavelfeldman]

No strong preference here. I would still optimize for n -> 1 and see if there is any confusion / incoming bug reports.

My thinking here is that empty CALL STACK is not alarming since that's what most users saw when working with a single session / single thread anyways.