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 ;)