Bug: DataGrid Column Filtering stops working

[djb-fnz]

I have observed a strange behaviour with the DataGrid filter button where it sometimes becomes unresponsive and then attempting to filter/sort on another column causes multiple filter dialogs to appear.

I can reproduce this behaviour on the main site:

https://blazorblueprintui.com/docs/components/data-grid

20260726-0346-35.2179882.mp4

[mathewtaylor]

Thanks for the report and the video, @djb-fnz — and apologies for the slow response. I've reproduced both symptoms and narrowed the mechanism a long way, but I do not have a fix yet, so I'd rather put the findings here than leave the issue silent.

A much sharper reproduction

It is not intermittent, and it does not need two columns:

1. Open any DataGrid column's filter popover.
2. Click anywhere outside it.

That filter button is now dead for the rest of the session. No amount of clicking reopens it.

Your "sometimes becomes unresponsive" is deterministic once you know the trigger — the intermittency is probably just how often a click lands outside versus on another control.

What the DOM shows

After that dismissal the component is in a state it is not supposed to be able to reach:

trigger aria-expanded	true
popover content in the DOM	absent
trigger pointer events	disabled

BbPopoverContent renders through IsOpen && State.TriggerElement.HasValue, so content can only vanish while IsOpen is true if the trigger reference has been lost.

The unresponsiveness follows from the same state rather than being separate: while a trigger context is open, BbButton applies pointer-events-none (mirroring the pointer-events: none the non-AsChild trigger button sets directly). A popover stuck "open" therefore has a permanently unclickable trigger. Recovery would normally come from clicking outside or Escape — but BbPopoverTrigger.Toggle deliberately only opens, never closes, so once the dismissal path has already run there is nothing left to reset it.

Your second symptom is the same root state. Opening a second column's filter while one is stuck leaves two triggers reporting aria-expanded="true" with only one panel rendered — which is what surfaces as multiple filter dialogs once you start moving between columns.

What I ruled out

Recording these so nobody re-walks them:

• @onclick:stopPropagation on the filter wrapper blocking dismissal — no. The click-outside listeners are registered on document in the capture phase, on mousedown/mouseup, so they run before propagation is stopped and are unaffected by a click handler.
• The click-outside listener failing to attach — no. onClickOutsideByIds logs a warning when it cannot resolve its element, and none appears.
• CleanupAsync clearing the trigger reference — it does not touch TriggerElement.
• A stuck mount latch in BbFloatingPortal — _isMounted is correctly reset in its CleanupAsync, so a re-open should remount.

A real defect found on the way — but not this one

PopoverContext.Open(), DropdownMenuContext.Open() and HoverCardContext.Open() all do:

public void Open(ElementReference? triggerElement = null)
{
    UpdateState(state => {
        state.IsOpen = true;
        state.TriggerElement = triggerElement;   // overwritten with null when called without one
        ...
    });
}

Any caller reopening without a trigger — notably BbPopover.OnParametersSet reconciling a controlled Open back to true — erases the reference captured when the trigger was actually clicked, which is exactly the shape that would strand the overlay open-but-unrendered. TooltipContext already guards this with if (triggerElement.HasValue); the other three diverge from it.

Applying that guard to all three did not fix the reported bug — I verified, it still reproduces. So it is a latent defect worth correcting on its own terms, but it is not the cause here. I have not opened a PR for it, because unverified changes to overlay primitives are not worth the risk on their own.

Where I'd look next

Something re-sets IsOpen to true after the dismissal has already unmounted the content, or prevents the portal remounting. The prime suspect is the reconcile in BbPopover.OnParametersSet running against a stale controlled value: BbDataGrid tracks filter popovers in a per-column Dictionary<string, bool>, and a render carrying a stale true for a column whose context has already closed would drive exactly this. Making the grid close other columns' entries when one opens narrows that window, but did not close it either.

I'll pick this up again. In the meantime, if the workaround matters to you: dismissing with Escape rather than an outside click takes a different path, and is worth trying to see whether it avoids the stuck state.

[mathewtaylor]

Fixed in #491, merged to develop.

Your "sometimes becomes unresponsive" turned out to be fully deterministic, and the two symptoms are one bug — stale triggers accumulate, each still claiming to be open, which is what surfaces as multiple filter dialogs once you move between columns.

Two faults compounding.

BbDataGrid — SetFilterPopoverOpen mutated its dictionary without touching any version counter ShouldRender gates on, so the grid skipped the re-render that would have carried the new value down. BbPopover never received fresh parameters after the open, and its _state.ControlledValue — refreshed only in OnParametersSet — stayed at its initial false.

BbPopover — this is what made it permanent. HandleContextStateChanged compared the context's new state against _state.Value, which in controlled mode is that stale ControlledValue. On the dismissal it compared equal, so OpenChanged never fired and the grid's own flag stayed true, permanently disagreeing with the context. The same single if also wrapped StateHasChanged(), so the subtree never repainted and the trigger kept the markup it had while open. Any later grid re-render then pushed Open=true back through OnParametersSet → _context.Open() with no trigger element → open, unrenderable, and unclickable. That is precisely the DOM state recorded above.

The fix compares against the state last actually reported to the consumer, which needs no consumer render to stay current, and moves StateHasChanged() out of the guard entirely — whether the content is mounted, and the trigger's aria-expanded and pointer-events, all derive from context state, so the subtree has to repaint whenever that state moves. Applied to all five overlay roots sharing the pattern (BbPopover, BbDropdownMenu, BbHoverCard, BbDialog, BbSheet), since any consumer overriding ShouldRender could reach it and the failure is silent and unrecoverable.

On the earlier note about TriggerElement being overwritten with null: that is a real defect and still worth correcting on its own terms, but it was not the cause here — which is why guarding it did not help. The trigger reference was never lost. The trigger simply never re-rendered.

Verified in a browser: three open/dismiss cycles plus a column hop now leave zero stuck triggers, and filtering still applies end to end. Convention tests cover both halves.

Thanks for the report and the video — the video is what made the second symptom legible.

[mathewtaylor]

Released in BlazorBlueprint.Components 3.16.0, live on NuGet now.

A column filter dismissed by clicking outside can be reopened. The underlying overlay state desync behind it is fixed too.

dotnet add package BlazorBlueprint.Components --version 3.16.0

Thanks for reporting it. Please reopen, or open a new issue, if it is not behaving as described.