How does this affect Disabled Tabs? Are there other edge cases we should look at?

How does this affect Disabled Tabs?

As I can see, none of the events is being triggered if the tab is disabled, and I didn't quite catch why.

As to the disabled portion it does have mud-disabled applied to that div you are modifying with the handlers which sets cursor to default, pointer-events to none and color.

So the TabPanel has both the onmousedown and onclick handlers, Which is firing first? Do we need both or can we change that onclick to fire Activate with the mousedown? There's some subtle interaction that is likely happening here, it resolves okay in your test and doesn't cause a problem though I worry about it. Your thoughts?

Do we need both or can we change that onclick to fire Activate with the mousedown?

My first thought was that, but I didn't want to make a change like that, as the @onclick carries the ActivatePanels logic on it. Instead, the new handlers will provide additional control over the tab, as we normally use the @onmousedown right away on other components, which unfortunately is not working with the MudTabPanel (https://try.mudblazor.com/snippet/cEQJFOcawqEXwDgO)

Should we support pointer down instead of the mouse specifically? For touch screens etc

Should we support pointer down instead of the mouse specifically? For touch screens etc

Isn't the problem that it doesn't support middle click? Which sometimes ppl request #11835 (comment)

Would it work if we supported arbitrary attributes through the existing UserAttributes dict:

<MudTabs @bind-ActivePanelIndex="Index" Border="true" Outlined="true" PanelClass="px-4 py-6" ApplyEffectsToContainer="true">
    <ChildContent>
        @foreach (var item in _tabs)
        {
-           <MudTabPanel Text="@item.Name" Tag="@item.Id" ShowCloseIcon="true" OnMouseDown="@(e => OnMouseDown(e, item))" OnContextMenu="@(e => OpenMenuContentAsync(e, item))">
+           <MudTabPanel Text="@item.Name" Tag="@item.Id" ShowCloseIcon="true" @onmousedown="@(e => OnMouseDown(e, item))" @oncontextmenu="@(e => OpenMenuContentAsync(e, item))">
                @item.Content
            </MudTabPanel>
        }
    </ChildContent>
    <TabPanelHeader>
        @if (context.ShowCloseIcon)
        {
            <MudIconButton Class="pa-0 mr-3" Icon="@Icons.Material.Filled.Close" OnClick="(_) => RemoveTab(context)" />
        }
    </TabPanelHeader>
</MudTabs>
// https://github.com/DrastamatSargsyan/MudBlazor/blob/dbbf743eda5ee00df9110408158720bcf110654f/src/MudBlazor.UnitTests.Viewer/TestComponents/Tabs/ClosableTabsWithHeaderTest.razor
}

-   RenderFragment RenderTab(MudTabPanel panel) => @<div @ref="panel.PanelRef" ...
+   RenderFragment RenderTab(MudTabPanel panel) => @<div @ref="panel.PanelRef" @attributes="panel.UserAttributes" ...

so any event/attribute can be used without needing new properties?

so any event/attribute can be used without needing new properties?

But it already does work with the MudButton, right? What's the issue with the MudTabPanel?

A little example showing the difference - https://try.mudblazor.com/snippet/cEQJFOcawqEXwDgO

Should we support pointer down instead of the mouse specifically? For touch screens etc

Isn't the problem that it doesn't support middle click? Which sometimes ppl request #11835 (comment)

It should likely be changed to mousedown to match the select/autocomplete rather than onclick imo. Which should give access to middle button and touch. As long as we make sure no side effects doable.

V

I would say merge this and for v9 switch to strict mousedown. My PR 12011 separates the click handler from activatepanel so it should be simple and good for a V9 change.