dotnet
Cursor position is incorrect after documentation comment element completion
Original title: VS 17.3.3 Razor editor writing documentation tags do nothing or work wrongly
Describe the bug: Writing XML documentation in Razor editor behaves like writing HTML in VS Code and does not react to some events. See video for comparison. Left Razor editor (not working), Right C# editor (working 100 % right).
https://user-images.githubusercontent.com/64279914/188279586-b9938eb8-0c76-42b0-8f4f-3bddf9472ddd.mp4
Cannot convert to GIF due to long video.
Note: these bugs were not present in VS 2019 Razor/Blazor editor when VS 2022 was released! They appeared when switching to VS 2022 which is required since the launch of .NET 6 in November 2021 to be able to work with .NET 6.
Version used: e.g. VS2022 VS 17.3.3
To reproduce: Steps to reproduce the behavior:
- Open any Blazor application
- Try writing XML documentation
Expected behavior: Working as C# editor.
Actual behavior: Not working or working incorrectly
Additional context: This has been happening since at least January 2022 in various forms and I thought was fixed but now is more broken than ever was before. I have been reporting stuff like these since January 2022 on VS Feedback.
https://developercommunity.visualstudio.com/t/VS-2022-Blazor-editor-code-docs-matching/1654591
Which leads here: https://github.com/dotnet/roslyn/issues/59773 This is clearly broken again now.
https://developercommunity.visualstudio.com/t/VS-2022-Blazor-editor---Writing-too-fast/1654948
https://github.com/dotnet/razor-tooling/issues/5617 This is clearly worse now because it didn't work on fast writing, now doesn't work at all (/// does nothing when waiting for the summary snippet to be generated)
https://developercommunity.visualstudio.com/t/VS-2022-Blazor-editor-buggy-and-features/1632233
and some more 15 tickets each with different Razor editor bugs.
How is this editor still in such very alpha version?
Thanks for the report @janseris!
Regarding the "not working at all" issue, it looks like https://github.com/dotnet/razor-tooling/pull/6495 got into 17.3, which caused this regression. It was subsequently fixed in https://github.com/dotnet/razor-tooling/pull/6550 which is in 17.4 Preview 1, and obviously will be in 17.4GA when it is released. My apologies that this wasn't fixed in 17.3, thats on me, it seems I (incorrectly) didn't think the break had got into any released version.
The video also seems to show the XML element completion being cancelled upon typing, which is tracked by https://github.com/dotnet/razor-tooling/issues/6455
Finally regarding the cursor being in the wrong position, I'll update the title of this issue and use it to track that, as I can reproduce that in 17.4 Preview 1 too.
How is this editor still in such very alpha version?
We are a small, but dedicated, team working to improve things, and we appreciate the issues that you've reported. Unfortunately we're only human, and sometimes bugs happen. It is unfortunate that you've hit this bug, after previously experiencing issues with the same feature, but all I can do is assure you that it is merely a coincidence in this case. There is no systemic plan to stop you writing documentation comments 😁
Looks like Roslyn is swallowing the caret information it has, when returning results via LSP. Logged https://github.com/dotnet/roslyn/issues/63811
There has been another attempt at solving this, but there are lots of issues across various teams/products to work through: https://github.com/dotnet/roslyn/pull/60499