Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.72%. Comparing base (bd89de1) to head (e63cbbf).
Report is 4 commits behind head on dev.

@@           Coverage Diff           @@
##              dev    #8369   +/-   ##
=======================================
  Coverage   88.72%   88.72%           
=======================================
  Files         407      407           
  Lines       12184    12196   +12     
  Branches     2429     2430    +1     
=======================================
+ Hits        10810    10821   +11     
  Misses        849      849           
- Partials      525      526    +1     

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

@henon @danielchalmers I think we have no other choice but use this compomise with

public abstract class XXX : MudComponentBase, IHandleEvent
{
    Task IHandleEvent.HandleEventAsync(EventCallbackWorkItem callback, object? arg) => callback.InvokeAsync(arg);
}

if we want this to be fixed #8365 and not come back to this issue #8151

That's the only combination to be working. Luckily the MudButton / MudFab / MudIconButton only have single EventCallback which is OnClick so it's fine to disable all re-renders of EventCallback within those components.

We need to check if MudAlert, MudChip, MudLink, MidMenuItem, MudNavLink, MudScrollToTop, MudSnackbarElement got the same problem after #8281, or it's just the buttons in case it's somehow related to MudElement?

We need to check if MudAlert, MudChip, MudLink, MudMenuItem, MudNavLink, MudScrollToTop, MudSnackbarElement got the same problem after #8281, or it's just the buttons in case it's somehow related to MudElement?

They are affected 😥 Removing AsNonRenderingEventHandler makes it back to normal...
We might need to partially revert #8281 and just leave the fixed tests and it will be just buttons from this PR.

God that's depressing 😭 and such an unpleasant workaround. It was a good optimization too

MudMenuItem EventUtil.AsNonRenderingEventHandler<TouchEventArgs>(OnTouchHandler) was important to my app. Is it just not feasible with this new approach?

When are you targeting a new release? Is it possible to hold off until MS has an answer? They're usually pretty quick

Is it just not feasible with this new approach?

I couldn't make it work with EventUtil no matter how and what I tried.

MudMenuItem

Well, technically we could add the IHandleEvent.HandleEventAsync to it too, as it has only single eventcallback that doesn't require re-render.

When are you targeting a new release? Is it possible to hold off until MS has an answer? They're usually pretty quick

I haven't yet reverted anything tho, @henon will have to decide what to do with this and about the release too.
But in general I'd say that ErrorBoundary is more important that the scroll issue.

@ScarletKuro We'll revert the problematic changes for now, or use the workaround you have found, whichever appropriate per component. Reverting has proven to be a good solution in the past because otherwise we are drowned in issues and questions on discord and we can't know when microsoft will fix the bug.

So is this PR ready to merge?

So is this PR ready to merge?

I will fix the typo tonight after work then merge this PR.
Then create another PR with reverting the #8281 partially and apply the workaround where applicable.

• MudAlert
• MudChip
• MudLink - MudLink: Fix exception doesn't flow to ErrorBoundary. #8375
• MudMenuItem
• MudNavLink
• MudScrollToTop
• MudSnackbarElement

Unfortunate but let me know if I can help to get things working again. Thanks for all the work on managing this stuff