Before:

After:

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.23%. Comparing base (5f4d7c6) to head (a24111b).
Report is 85 commits behind head on dev.

@@            Coverage Diff             @@
##              dev   #10122      +/-   ##
==========================================
+ Coverage   91.18%   91.23%   +0.05%     
==========================================
  Files         411      411              
  Lines       12480    12484       +4     
  Branches     2431     2431              
==========================================
+ Hits        11380    11390      +10     
+ Misses        556      552       -4     
+ Partials      544      542       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I don't know how to make codecov happy.

This also fixes: #8124

I fixed all the problems etc.
The style check you possible could grab from the popover if you want. But as you can see the codecov doesn't complain anymore.

But I think using the DataGrid in the OpenMenuAsync_Should_Set_FixedPosition() aka DataGridContextMenuTest is too heavy.
I would rather just use the code for testing from the #8124

upd: anyway, going bed now, its very late and I'm doing more and more typos in the text.

P.S. I also noticed it's writing in AnchorOrigin, but considering it's old code and was there before, I'm not going to bother for now. This is task for later.

The context menu example is broken, the menu is being rendered to the page:

When you click it the wasm app crashes.

@ScarletKuro
In WASM any line that does this or similar causes the app to crash (is not particular to the context menu) and they all work in Server Mode.
await httpClient.GetFromJsonAsync<List>("webapi/periodictable")

The context menu example is broken, the menu is being rendered to the page:

When you click it the wasm app crashes.

@ScarletKuro In WASM any line that does this or similar causes the app to crash (is not particular to the context menu) and they all work in Server Mode. await httpClient.GetFromJsonAsync("webapi/periodictable")

Are we talking about MudBlazor.Docs.Wasm? That's expected since it's doing API call, but there is no server running with the controlled, so just ignore it.

That invisible menu shouldn't be rendered in the first place

That invisible menu shouldn't be rendered in the first place

If I understand what you are saying, all the popovers work that way, inspect a page with a mudselect, mudautocomplete, tooltip, etc find the popover provider element and every popover will be listed there just not visible. The visible ones will have a data-ticks attribute > 0

That invisible menu shouldn't be rendered in the first place

If I understand what you are saying, all the popovers work that way, inspect a page with a mudselect, mudautocomplete, tooltip, etc find the popover provider element and every popover will be listed there just not visible. The visible ones will have a data-ticks attribute > 0

Are we talking about the Popover Provider? Unfortunately, on this screen, I can't tell if it is coming from the provider or not. If it is, then that’s expected and unrelated to this PR, it will list all popovers inside it as invisible with empty content. When Open=true, they become visible with their content.

This was architected this way long before I joined the team, I only boosted the performance, but the principal is still the same.

looks like what's mentioned isn't from the provider after further research but also it's required. Popover needs a parent to place itself. There's nearly nothing in it, the actual menu is with the provider.

<div id="_contextMenu" class="mud-menu"><!--!--><!--!--><button type="button" class="mud-button-root mud-button mud-button-text mud-button-text-default mud-button-text-size-medium mud-ripple" _bl_649=""><span class="mud-button-label"></span></button><!--!--><div id="popover-d0144102-d780-4ada-9c36-f1aeeba99cee" class="mud-popover-cascading-value"></div><!--!-->

    <!--!--><div class="mud-overlay" style=""></div></div>

So to summarize the invisible element needs to be there, but clicking it shouldn't cause a crash, I guess.

The invisible element must not:

• be visible (so users or screen readers don't get confused)
• be clickable (so the crash condition is impossible to produce)
• take up any space (so it doesn't break the layout)

Currently the menu renders as an empty button. IMHO this button element should not be rendered at all.

I was able to reproduce the issue with this example:
https://github.com/MudBlazor/MudBlazor/blob/43fbb956b46650885a4b25230fece4a1c81ed253/src/MudBlazor.UnitTests.Viewer/TestComponents/DataGrid/DataGridContextMenuTest.razor

There is indeed a hidden clickable element that crashes both server-side and wasm.
The stack trace:

blazor.web.js:1 
 crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at MudBlazorWebAppAuto.Client.Pages.Counter.<BuildRenderTree>b__0_14(RenderTreeBuilder __builder3)
   at Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder.AddContent(Int32 sequence, RenderFragment fragment)
   at MudBlazor.MudMenuItem.<BuildRenderTree>b__53_0(RenderTreeBuilder __builder2)
   at Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder.AddContent(Int32 sequence, RenderFragment fragment)
   at MudBlazor.MudListItem`1[[System.Object, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<BuildRenderTree>b__141_3(RenderTreeBuilder __builder3) in C:\Users\KuroPC\source\repos\MudBlazor\src\MudBlazor\Components\List\MudListItem.razor:line 51
   at Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder.AddContent(Int32 sequence, RenderFragment fragment)
   at MudBlazor.MudText.<BuildRenderTree>b__37_0(RenderTreeBuilder __builder2)
   at Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder.AddContent(Int32 sequence, RenderFragment fragment)
   at MudBlazor.MudElement.BuildRenderTree(RenderTreeBuilder builder) in C:\Users\KuroPC\source\repos\MudBlazor\src\MudBlazor\Components\Element\MudElement.cs:line 99
   at Microsoft.AspNetCore.Components.ComponentBase.<.ctor>b__7_0(RenderTreeBuilder builder)
   at Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(RenderBatchBuilder batchBuilder, RenderFragment renderFragment, Exception& renderFragmentException)

When clicking on it, the popover opens BUT this PR is not the cause of the issue. Setting PositionAtCursor to false or completely reverting this commit does not fix it. Therefore, I am removing the regression label from this PR.
I don't see anything in the example that would cause this hidden thing to showup, so I think we should look the problem somewhere else than look it in the example?

In fact, it's even reproducible on v7: https://try.mudblazor.com/snippet/wkQolPwMqOAZytWz

Null exception is fixed in #10352