Difficult to type a div in razor that's in a code block in another div

[vsfeedback]

trafficstars

This issue has been moved from a ticket on Developer Community.

---

[severity:I'm unable to use this version] I'm trying to add a div inside the foreach block below in a Razor file:

<div>
    @foreach (var item in items) 
    {
        // Add a div here
    }
</div>

When I type the opening div tag, the editor matches it with the closing div tag outside of the foreach block instead of generating a new closing div tag.

If I try to type the closing div tag it gets automatically completed as an opening div tag with a closing div tag, which is really frustrating.

! [6UCAcPkig4.gif] (https://aka.ms/dc/image?name=Becc54d8041ca4b51b86fc72adf62ae0d637711474345224136_20211029-163713-6UCAcPkig4.gif&tid=ecc54d8041ca4b51b86fc72adf62ae0d637711474345224136)

---

Original Comments

Feedback Bot on 10/31/2021, 10:40 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[NTaylorMullen]

Can reproduce this with typing > here:

<div>
    @foreach (var item in collection)
    {
        <div|
    }
</div>

[NTaylorMullen]

Investigated and the compiler is being "greedy" in its resolution of HTML elements with the same tag when inside of a C# block. This isn't always a bad thing; however, in this case we could be smarter when nested in a C# block. We could change the "fallback" behavior of HTML tags. Soooo what's happening is the second <div> and </div> are being paired together ignoring the parent. This then results in us failing to auto-complete the tag. Now that being said HTML itself has a similar issue which I've reported here, although they don't have the concept of the outer C# block.

Anyhow, here's a screenshot from https://razorlab.azurewebsites.net/ with how the Razor compiler is interpreting this:

Moving over to compiler + following up on the WebTools side to make this happen. /cc @danroth27 since you were the original reporter.

[NTaylorMullen]

More reports:

• https://developercommunity.visualstudio.com/t/Razor-files-not-working-correctly/1578833
• https://developercommunity.visualstudio.com/t/So-many-things-arent-working-that-I-don/1598121

[jimmylewis]

I've just submitted a fix for the VS HTML editor (and should show up in the Razor editor) that will handle this case better. Like Razor (as @NTaylorMullen showed above), the HTML parser associates the close div with the inner open div, but now we'll try to detect if there's a possibility that it could be ambiguous and still offer the </div> completion.

There's a secondary issue called out here too where when you type </ we show start tag completions, and if the VS client selects that, you'll type </div> but VS will complete <div>. I've also submitted a change so that when we see </ we won't show start tag completions.

The changes are slated for 17.1 Preview 3.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[NTaylorMullen]

Another report: https://developercommunity.visualstudio.com/t/Blazor-Intellisense-not-working-with-div/1603452

[tbasallo]

Did I read this right that in Dec 2021 it was decided to review for .net 7?

This issue is causing all sorts of buggy behavior in VS. And the developer community issue reports are just closed out to "duplicate" - but this makes VS2022 almost unusable. I have been using VS for a long time and I am considering try other IDEs because of how bad this is.

[danroth27]

Hi @tbasallo. This issue is taking a long time to resolve because it requires significant changes to the Razor compiler. These changes are in progress.

[tbasallo]

@danroth27 thanks for the update.

I am glad to hear changes are in progress. As fellow developers I know that we all understand the pain of having a bug/fix that we can't get out fast enough. But this one is particularly frustrating - even more so since I am unsure how many other Razor editor quarks/bugs are related this or something else.

Hopefully the fix will come out soon.

[allisonchou]

Another report: https://developercommunity.visualstudio.com/t/HTML-In-Razor-If-Statement-Blazor-net-/10120457

@chsienki @333fred if possible, could we have this issue prioritized for an upcoming sprint? There have been multiple customer reports.

[333fred]

@allisonchou I don't know what you're expecting us to do differently here. As I've said on similar issues in nested contexts, the only way that we can change this is by re-engineering error recovery in the compiler to do significant amounts of error recovery and backtracking. Possible, yes, but it's more than a single sprint of work. It sounded like Taylor needed to follow up with the web tools team?

[danroth27]

As I've said on similar issues in nested contexts, the only way that we can change this is by re-engineering error recovery in the compiler to do significant amounts of error recovery and backtracking

@333fred Are you recommending that we shouldn't do the re-engineering work on error recovery in the compiler? Or are you just clarifying that it will take some time (longer than a sprint)? If it's the later, then that's completely understandable. The ask here is simply to make sure that the work gets prioritized and doesn't get unnecessarily delayed.

It sounded like Taylor needed to follow up with the web tools team?

@333fred I assume Taylor was referring to following up with the Web Tools team about https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1431961, which has since been fixed and closed. @NTaylorMullen Can you confirm?

[333fred]

Or are you just clarifying that it will take some time (longer than a sprint)?

I'm saying this one. It's a significant chunk of work.

[tbasallo]

Is there a different issue that we can track to determine if there's progress being made?

Every preview version of VS2022 that is released I hope to see this issue fixed (or improved) and I've not seen or heard of progress. Honestly, from the outside, it feels like this is a low priority item. I see new features in VS being released, which are nice and cute and cool - but do not impact me anywhere near the way this issue does.

I am not sure how many of the VS devs on the team do the impacted kind of work daily - but this makes using VS a real chore and I am really hoping for some progress and fixes in this space.

I can definitely say that based on the general comments around this issue on forums like Reddit, Twitter, etc. - devs are suffering through this.

For the first time in two decades, I am considering changing to a different IDE. Probably Rider since it seems to be a competent competitor based on streamers and videos on YouTube. I don't mean that as a threat as much as it's gotten to the point that I am easily losing 15% efficiency everyday by not having Intellisense to speed me up and having to clean up all the wrong things that the editor wants to do that don't make sense. Not to mention frustrations.

Please share some good news with us!

[chsienki]

Hi @tbasallo,

I appreciate that this is taking a long time, but I can assure you that it's not a low priority for us. We understand how much it hurts developers and are determined to get it fixed.

The razor compiler is a complicated piece of code that has been added to by various teams over the years. Unfortunately, we've gotten to the point where it's no longer feasible to just 'add one more thing' and we need to restructure some of the deep internals to make sure that it works correctly going forward. A lot of this work has just basic infrastructure stuff, and we're only now getting to the point where we can actually start remaking the foundations.

VS is a large product with a large team, but the number of people working directly on the Razor compiler is comparatively small. We're workin' our butts off to get it done, but there's only so many hours in a day :). I know that it would be a lot more satisfying if I could just answer 'this will ship in preview X', but hopefully this lets you know that we really do care, and really are in the process of trying to fix it.

@333fred Do we have a better issue or an umbrella issue that can be used to track the error recovery improvements and what needs to be done beforehand?

[tbasallo]

Checking in to see if any progress has been made?

[tbasallo]

It's been nearly 2 years since this was moved here. I say the following not to somehow shame the group, but to really shine a light on how horrific the experience is in VS 2023 Professional, including the Preview versions, today. I work from three different machines and they all exhibit the same issues. Working in VS is a constant correction of what it wants to do - it's auto-correct issues x 1000. And while I appreciate that everyone that has commented understands it's important, it does not seem to be making any appreciable improvement. In the meantime, more and more features are being added with nary a mention of how buggy the editor experience is once you introduce code. I may be the one guy that is suffering or everyone else has moved on (or living with it). Perhaps everyone moved onto other IDEs if they code Razor/Blazor pages. (C# works perfectly). Maybe they left to VS Code.

I start next week to use Rider - purchased last week on special and if it works as well (better?) as some folks say (Nick Chaspas, for one) we'll move our team to it and will be the recommended IDE (and cheaper than VS even at full price). Honestly, JetBrains should take advantage of the VS editor's issues and promote Rider - they'd surely get a bunch of users (the ones still hanging on).

Related: #8399, #7608, #8976, #8047, and many, many more. If you were to combine them with emojis showing support I am sure the overall impact on users would be more obvious.

Again, while I appreciate what @chsienki, @danroth27, @333fred and the rest have said about being important, but hard to fix - this is not OK. The main editor for Razor and Blazor pages needs to be prioritized and fixed.

By VS and Hello

[LuohuaRain]

@tbasallo However, Rider's Hot Reload feature isn't as good as Visual Studio's.

[tbasallo]

That may be true, I've been setting up Rider all day - no coding yet. But Hot Reload is only passingly useful. I usually have to restart after an hour or so of coding because EVERY change requires a rebuild.

[leetheman]

Hi this affects me too and is quite frustrating as often razor components have a code block to cover the rendering e.g @if(IsLoading) { }

this means that my entire HTML structure that goes inside the block has to be written outside and then moved in, otherwise it takes me twice as long. Also includes features like "surround with

" which is super helpful for styling etc.

[tbasallo]

#bump - 3 years later, still here suffering along only mildly better.