Can't set breakpoint on razor expression in html attribute

[dgoldm]

I previously reported this issue: Can't set breakpoint on razor expressions in .razor file #9208 Which has been fixed.

But it turns out that the fix isn't complete.

Although I can now set a breakpoint on an expression in the inner html of an element, e.g.: <p role="status">Current count: @currentCount</p>

I still can't set one on an expression within an html element's attribute. e.g. on the expression @(currentCount > 3) in the following html: <button class="btn btn-primary" @onclick="IncrementCount" disabled="@(currentCount > 3)">Click me</button>

This does work in cshtml files.

Tested in VS 17.9 preview 3.0

[davidwengier]

@dgoldm Thanks for the report, but unfortunately I'm unable to reproduce this issue. Granted I'm on 17.9 Preview 5, but we haven't made any changes that I would think would affect breakpoint placement. How are you setting the breakpoints? I tried by clicking in the margin, and hitting F9 at the start and end of the line, and inside each expression. In particular I'd be curious to know if it works for you to place the caret inside the currentCount expression, and hit F9, and let us know what happens.

This is what I get:

I guess another thing to try would be to check if it works if you remove the @onclick attribute altogether, or change the order of the attributes etc.

[dgoldm]

Thanks @davidwengier. I'm sorry for not elaborating enough. When at rest, indeed it looks as if the breakpoint has been set, as can bee seen in your clip. But once I run the project the breakpoint jumps to the first executable line in the code block, and that's the place that the debugger stops on, not in the attribute where I originally set it.

[davidwengier]

Thanks @dgoldm !!

This is actually kinda funny because at triage this morning we were discussing this issue, and @phil-allen-msft said he ran into a bug where breakpoints moved and we all said "yes, but that's not what @dgoldm is experiencing". Guess we were wrong 😀

[davidwengier]

@tmat any pro-tips for breakpoints switching between design time and runtime? would we get a ValidateBreakpoint request, or is it all up to the (Razor/C#) compiler with sequence points, line mappings etc.?

[tmat]

There are a couple of features related to breakpoints that have separate implementations but need to match on the results. The impls are separate because each has different inputs.

1. debugger understanding (for stepping, binding breakpoints, active statements, etc.) - this is entirely driven by sequence points in the PDB. Razor could tweak these via #line directives.
2. Breakpoint placement and tracking. This is where the IDE decides where to put breakpoint span given location in the code. This is based on syntax. LSP ValidateBreakpoint invokes the language service that determines the span location. It's also used to adjust the BP span when source is edited around it.

[davidwengier]

Okay, we had a bug in ValidateBreakpoint but even after fixing that I can still repro this issue. The #line directives in the generated files look to match (design time on the left, runtime on the right) so I'm not sure where this needs to go next.

Would an enhanced line directive help in some way? Or is it a fundamental difference in sequence points between a method parameter (runtime) and a field assignment (design time)?

[dgoldm]

If I correctly understand the above - "@davidwengier closed this as completed in #9905 Feb 6, 2024", this issue was supposed to have been fixed in version 17.10 preview 2. I just updated VS to preview 2, and the problem still persists.

[davidwengier]

Thanks for catching that @dgoldm, this definitely shouldn't be closed. Not sure if I did that manually accidentally, or some automation on GitHub did it, but either way I'll reopen.