Allow debug adapter to control which frame to focus when stopping (eg. on exception)

[DanTup]

This is slightly related to #64193. The current expected behaviour is that VS Code walks up the stack frames and focuses the first frame that has source code (though it's not working correctly due to that bug).

However, assuming "the first frame with source" is the one that is most relevant isn't the best option. For example some languages/frameworks may ship source code for their internal libraries which means often the implementation of an assert method may have source - and this will result in the user looking at that implementation when it may be more appropriate to be looking at their call to it.

It would be best if the debug adapter could explicitly control which frame to focus when an exception is hit (most simply would probably be a flag on the frame for whether it should be excluded from auto-focus, and that flag used in place of the current "has source" check, but it could also make sense in the StoppedEvent).

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Restart Frame While Debugging TS Jumps To JS Source (#25473)
• Can't trigger "Load more Stack Frames" with keyboard (#64834)
• Breaking on exception should jump to top frame that has source (#64193)

[weinand]

In general this is a valid request.

However, I wonder how realistic it is for a debug adapter to determine the "best frame to focus on" without any help/hints coming from the user.

Based on this observation here is an alternative proposal based on an existing concept:

VS Code has already the concept of "uninteresting" source. This is surfaced in node-debug via the "skipFiles" glob attribute (which is not part of DAP). Whatever source matches that glob gets the special presentationHint deemphasize.

VS Code uses this hint to render stackframes in a dimmed style and collapses adjacent frames into one. We could easily extend VS Code notion of "deemphasized" sources by ignoring them when determining the best frame to focus on.

So in your case you could just return the deemphasize hint for source/frames that should not be focused. And if you can provide this hint even without introducing something like a "skipFiles" glob attribute, then even better.

@DanTup what do you think?

[DanTup]

However, I wonder how realistic it is for a debug adapter to determine the "best frame to focus on" without any help/hints coming from the user.

In this case I'm trying to focus on "user code" rather than "framework code", so I think the DA is best placed to know this.

So in your case you could just return the deemphasize hint for source/frames that should not be focused.

We actually already set this to get the collapsed stack traces, so using this would be perfect for me. We even let the user control this by opting in to debugging framework code if they want, so this would also be more flexible.

[weinand]

So then let's go with this approach.
@isidorn please consider this when fixing #64193.

[isidorn]

@DanTup I have pushed a fix for this, please try it out in the insiders after we start updating it again after holidays (in 10 days).

[DanTup]

@isidorn Tested in insiders, and it now skips the deemphasize frames and goes to my source - thanks!

[isidorn]

Thanks for trying it out. Adding verified label