fix: v5 FluentTabs get stuck switching infinitely

[AntonZhernosek]

🐛 Bug Report

In the new v5 version of the library FluentTabs very often get stuck in infinite switching loops

💻 Repro or Code Sample

Reproducible on the demo site by clicking through tabs quickly. Not very consistent though, and seems to repro better on a slower laptop for me.

tab-jumps.webm

The video shows it when clicking add, but I've also been able to repro the same thing on another device by just switching tabs around. It would also just sometimes freeze the page completely and force me to kill the tab.

One clue that could help in debugging from my side is that rendering heavier tab content and switching around seems to repro the issue more consistently.

Also, I find it harder to repro on root tabs, seems to be easier to repro on nested tabs (FluentTabs displayed as content of another FluentTab).

💁 Possible Solution

Haven't found a good workaround for it, unfortunately. All the components being upgraded from v4 to v5 bind ActiveTabId. It seems like unbinding it improved things a little (makes it harder to repro), but does not eliminate it entirely.

I think it's an issue with the rendering loop of state updates between tabs parent -> tabs -> native library logic and repeated event handling/ActiveTabId forwarding logic.

I haven't tested the js library without the Blazor wrapper, so it might be worth trying to repro it there too and it might not strictly be this library's issue.

🌍 Your Environment

Seems to be browser-agnostic (tried on Firefox and Chromium-based browsers)

[menees]

We hit what looks like the same behavior while upgrading a large Blazor Server app to 5.0.0-rc.5, and we were able to pin down a deterministic trigger that produces this kind of loop.

Mechanism we observed: FluentTabs raises ActiveTabIdChanged while tabs are unregistering, and it reports the first remaining tab as the newly active tab, even when the active tab is not the one being removed. Tabs unregister in bulk whenever the strip is recreated (a @key on FluentTabs, or conditionally rendering the tabs/one of the tabs) and when the user navigates away from the page. So the sequence is:

1. Something re-renders or recreates the tab strip (data load completes, a tab's condition flips, navigation starts).
2. Each unregistering tab fires ActiveTabIdChanged with a bogus "first remaining tab" value.
3. If the handler reacts by updating state or the URL (a common pattern when the active tab is bound to the route), that causes another render/recreation, which unregisters tabs again, and the cycle repeats.

In our case this manifested as: selecting an item announced tab A active while the URL and user were on tab B, an infinite navigation loop between two tabs, and ActiveTabIdChanged firing repeatedly during page teardown (which "navigated the user back" to the page they were leaving). That matches the "stuck switching infinitely" symptom here, and would plausibly be amplified by nested tabs since each inner strip adds its own unregister events.

Workarounds that made it stop for us:

• Never recreate the strip: no @key on FluentTabs, and never add/remove FluentTab components conditionally. Keep the tab set stable and toggle FluentTab.Visible instead.
• Guard every ActiveTabIdChanged / @bind-ActiveTabId:after handler so it ignores reports that arrive when the change cannot be user-initiated (for us: only sync the URL while the page state that hosts the tabs still exists, and only navigate if the current location is still within the page's route).

Suggested fix direction: don't raise ActiveTabIdChanged from the unregister path at all unless the tab being removed is the active tab, and never during component disposal/teardown.