Show visual hints for inline breakpoints

[auchenberg]

In #14784 we implemented column breakpoints which is now available for our Chrome and Node debuggers, but discoverability of this very useful feature is rather limited, as you have to set column breakpoints via shift+F9.

Chrome DevTools recently shipped inline breakpoints that's a UI on top of column breakpoints, that work's by a user setting the initial breakpoint by clicking on the line number. Light blue markers now appear on this same line next to any place where an inline breakpoint can be set.

Details: https://umaar.com/dev-tips/129-inline-breakpoints/

The rationale

We want VS Code to be the best place for editing for JavaScript developers, and column breakpoints has shown to be helpful especially for developer debugging promise-based flows. Adding visual hints for column breakpoints will provide value to our JavaScript developers and will also bring the VS Code debugging experience on pair with Chrome DevTools.

We already support Column breakpoints and given that two of our top debuggers Chrome and Node already supports getPossibleBreakpoints, it's relatively low effort to implement this functionality.

The experience

1. User sets regular/initial breakpoint by clicking on the line number.
2. Light red visual hints (similar to how to show hints in the gutter) now appear on this same line next to any place where an inline breakpoint can be set.
3. User can not toggle these visual hints into column breakpoints (same as pressing SHIFT+F9 at the location)

Visual hint

Column breakpoint set

Arguments against

1. Only a few debuggers supports column breakpoints, and therefore we shouldn't prioritize this functionality unless more debuggers gain support.

Technical details

Chrome/Node has implemented a new Debugger.getPossibleBreakpoints that returns a list of the possible breakpoint locations, which is used to light up the visual hints

VS Debug Protocol

I assume the VS Debug Protocol could have to get extended to support this?

[weinand]

Please note that column breakpoint positions are only available if a debug session is active. So discoverability is not improved if no session is active.

Yes, the debug protocol can always be extended. But it already supports something related: https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts#L898

[auchenberg]

Good point. I don't think it would be blocker for the experience, as I imagine developers will set "inline breakpoints" as a part of a workflow where a debug session is active. That said I don't have any data to back this up.

[weinand]

The bigger issue is the way we currently decorate everything "inline" (i.e. column breakpoints or inlined variable values). This is based on a mechanism that doesn't scale well. So Alex considers this "debt" that we should fix before we make more use of it...
So we'll talk to him.

[isidorn]

@auchenberg when we initialy implemented column breakpoints we first looked into this experience. However due to techinical limiations we went with the current approach.
The difference between vscode and dev tools is that dev tools has the AST understanding of the file and can propose potential candidates for column breakpoints while vscode does not have this knowledge. One idea was to get this data from the debug adapter but then you are running into the limitation that Andre pointed out - and this is currently not supported in the protocol.

And I agree of course that this experience is much better than our current one.

[auchenberg]

@isidorn Gotcha. This could potentially be provided by the JavaScript language server, right?

Chrome DevTools is making the getPossibleBreakpoints to get the potential candidates, and our first version could be doing the same, with the caveat of a running debug session is needed.

[isidorn]

@auchenberg in theory this could be provided by the language server

[weinand]

@auchenberg the JavaScript language service is an implementation detail of the JavaScript extension. So VS Code has no access to it. In addition the LSP does not (yet) support any debug specific functionality.

Here are three architectural options we have to connect debug extension with language extension:

• we introduce a new abstraction "LanguageDebugProvider" for extensions that the generic VS Code debug UI could use to get access to language specific debug support. The JavaScript extension could implement this provider by using the JavaScript language service.
• a debugger extension (e.g. node-debug2) accesses the language service directly because it "knows" that there is a JavaScript Language Server running (and it fails gracefully if it cannot find the server). The LSP would probably need new debug-specific protocol for this.
• a debugger extension and a language extension are merged into one extension. Here the language server can be easily shared. I believe Java is using this approach. VS Code supports to run debug adapters in server-mode (instead of session-mode). With this it is possible to have a single process that serves both protocols, the language and the debugger protocol.

[auchenberg]

@weinand I think this could be implemented simpler without tight integration between LSP and DAP's.

1. LSP could emit potential break locations, which lights up as hints in the editor as the file is parsed.
2. Clicking a hint would set a column breakpoint
3. Setting a breakpoint, triggers regular breakpoint/DAP flow.

Possible?

[weinand]

@auchenberg I don't think so.
But please prove me wrong by submitting a PR.

• I'm not aware that LSP supports potential break locations.
• VS Code knows nothing about LSP, and it does not assume that a language is implemented via LSP.

BTW, VS Code's TypeScript/JavaScript extensions does not use LSP.

[auchenberg]

@weinand Well you know quite a bit more about the architecture of Code, DAPs and LSP than me, so I trust you on this ;)

[isidorn]

Even though this is a muscle item for the february milestone @weinand informed me that we already have protocol to support this, however the adapters are not implemetning this yet.
Also assigning to @roblourens to investigate when he has cycles if node2 could support this funtionality.

[roblourens]

It could 👍

https://chromedevtools.github.io/devtools-protocol/v8/Debugger#method-getPossibleBreakpoints

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[auchenberg]

@weinand I still think this is a feature we should land to improve debugging of arrow functions in JS, which we are seeing a growing usage of.

Right now inline breakpoints aren't discoverable, and visual hints is a big improvement for this.

[weinand]

In order to support this feature, we need a new DAP request for finding the possible Breakpoints for a source line. I've created microsoft/debug-adapter-protocol#72 for this.

[isidorn]

@roblourens since we added support for this on the vscode side could you look into adding support for the breakpointLocationRequest this for node2 and chrome? It would be very cool if we get this.
I can also create issues in the node debug 2 and chrome repository if you would prefer to have it tracked there?

[isidorn]

Here's a demo with Mock Debug

[isidorn]

Closing this issue since vscode now supports this.
I have created https://github.com/microsoft/vscode-chrome-debug/issues/934 and microsoft/vscode-node-debug2#242 for chrome and node-debug respectevely.
Thanks