How to fix "Fast clicking bug"?

[SergeyB (SerKocapb)]

Many components suffer from an annoying bug that manifests when rapidly clicking on their elements.
This bug prevents the component from synchronizing the state of its child elements, resulting in an infinite re-rendering loop.
I am not sure what is happening internally, but on the screen, I see the interface elements' styles rapidly changing without any further user interaction.
You can reproduce this bug yourself—with a bit of practice—on the following pages:

1. https://fluentui-blazor.net/TreeView
2. https://fluentui-blazor.net/Lists/Listbox
   Try rapidly clicking on two adjacent items in the tree or list.

It seems to me that such behavior is not merely unseemly but potentially dangerous—for instance, if the server performs calculations, accesses a database, or the like, in response to a change in component state.

I realize this is likely a Blazor issue rather than a FluentUI one, but is there a way to prevent this component behavior?

[Olawale Abaniwonda (HadrielWonda)]

I reproduced this on the Listbox demo page and traced it. It isn't Blazor itself. It's a feedback loop between the server render and the listbox's own change detection, and it doesn't settle on its own.

What I measured (headless Chromium against https://fluentui-blazor.net/Lists/Listbox, alternating clicks on Red and Green 15 times, then no input at all):

• No click or change DOM events fire after the clicks stop.
• The browser keeps sending listchange events to the server: 74, 35, 77, 78, 83 and 82 in each 5-second window over the next 30 seconds.
• Each one is followed by a render that flips the selected attribute between the two options.

Why it loops

ListBoxContainer.ts watches the options' selected and current-selected attributes with a MutationObserver (L274, L311) and dispatches listboxchange whenever the selection differs from the last one it reported (L325-L348). FluentListbox handles that as a user selection through @onlistchange.

The observer can't tell a user's click from a server render, because both change the same attributes:

1. You click Red, then Green, faster than the round trip. Two selections are in flight.
2. The server applies Red and renders. The render changes selected, so the observer reports Red.
3. Meanwhile the server applies Green and renders. The observer reports Green.
4. Each report is a real change from the previous one, so the "skip if unchanged" guard at L333 never stops it, and every report causes another render.

That's why you see the styles cycling, and why your concern is valid: any handler bound to the selection runs again on every cycle.

What you can do now

• Keep expensive or side-effecting work out of the selection-changed handler. Trigger it from an explicit action (a button), or make it idempotent and cheap. A debounce won't help, because the events never stop.
• If you can, report it on the repo as a bug with the steps above. The fix belongs in the library: dispatch listboxchange from the click and keyboard handlers instead of from the attribute observer, or have the observer ignore mutations caused by a Blazor render.

I only verified the Listbox. TreeView may have the same cause, but I didn't confirm it.

[SergeyB (SerKocapb)]

Thank you for the work you’ve done in investigating this issue. I hope the FluentUI developers take this into account.

[Vincent Baaij (vnbaaij)]

Can either of you create a proper issue (with reproduction code/steps) for this. We want to keep issues and discussions separate. Thanks.

[SergeyB (SerKocapb)]

Unfortunately, I don’t have time for this right now. I will start working on it in about a month.
Taking this opportunity, I would like to thank you and the community for FluentUI.