You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add Activity dialog: Escape pressed before the select has loaded crashes the page (Fluent UI 4.14.4, tracking) #107
Tracking issue for the part of #105 that our code cannot fix.
Symptom. On Activities, open the Add Activity dialog and press Escape without touching anything. The page shows "Something went wrong on this page" (the error boundary). Seen in a live run on plain dev and on the tree with the #106 fix, so #106 did not change it.
Diagnosis (from the #105 worker; not independently verified by me). An ArgumentNullException inside Microsoft.FluentUI.AspNetCore.Components 4.14.4: a key press that reaches the select before the select has finished loading its script crashes it, including keys that close nothing. The worker reports the same code in 4.14.5.
Why it is tracked, not fixed. The only fixes available in our code would be a try/catch around the dialog or turning off the error boundary, which #105 ruled out. Dependabot PRs #71 and #72 move to Fluent UI v5 and stay open until that upgrade.
Next step. Re-run the Add Activity Escape flow when we move to Fluent UI v5. If it still crashes there, report it upstream with a reproduction.
Related.#105, #106 (fixed the ObjectDisposedException half), #71, #72.
This issue is deliberately not in a release milestone: it is waiting on the upstream library, not on us.
Measured note after #106 merged. The untouched Add Activity Escape flow in my live script (fresh Chromium per flow, Escape about 1.2 s after the dialog opens) gave:
That is 2 crashes and 2 clean runs across 4 runs, so the crash is intermittent. That fits a timing race (a key press arriving before the select has loaded its script), but I have not proven the cause. Four runs is too few to say whether #106 changed the rate.
Measured by the #54 follow-up worker (bisect, 50 runs of an early-Tab repro on /activities) and re-checked by Nerd on 2026-10-07.
The ArgumentNullException ... jsObjectReference comes from a Fluent UI race: ListComponentBase.OnKeydownHandlerAsync uses _jsModule before its import finishes (Fluent UI 4.14.4/4.14.5, per the worker).
Plain dev (1d3c1e2) has it: click in the search box on /activities and press Tab before the module loads, 5 of 5 runs crash (worker). Tabbing from the page top without a click: 0 of 5 on dev (Nerd).
PR fix(web): give icon buttons, dialogs, search boxes and selects accessible names #108's head (18dc0c1) crashes 3 of 3 on a plain early Tab from the top (Nerd). The worker's bisect says the cause is the new focusable h1 (focus now starts at the top of the content, so Tab reaches the select sooner), not the accessible names or focus.js.
With a 3 s wait before Tabbing, neither tree crashed in the runs made.
Not measured: how often real users hit this, and whether Fluent UI 5 changes it.
Deferred to the Fluent UI Blazor v5 migration (#81, milestone 0.8.0) by Woody's decision on 2026-10-07. Reading the v5.0.0 source (not run against EventManager): ListComponentBase and its C# keydown handler are gone, FluentSelect derives from FluentListBase, and neither file references _jsModule. The select initializes with one JS call on first render. Re-test the early-Tab and Escape-before-load flows on /activities once the migration lands. Not measured: any other early-interaction issue on v5.
Activity
mwg-bender commentedon Oct 6, 2026
Measured note after #106 merged. The untouched Add Activity Escape flow in my live script (fresh Chromium per flow, Escape about 1.2 s after the dialog opens) gave:
dev32caa0f: crashdev1d3c1e2 (fix(web): stop Escape in a dialog with a select from crashing the page #106 merged), two separate runs: no crash in eitherThat is 2 crashes and 2 clean runs across 4 runs, so the crash is intermittent. That fits a timing race (a key press arriving before the select has loaded its script), but I have not proven the cause. Four runs is too few to say whether #106 changed the rate.
mwg-bender commentedon Oct 7, 2026
Measured by the #54 follow-up worker (bisect, 50 runs of an early-Tab repro on
/activities) and re-checked by Nerd on 2026-10-07.ArgumentNullException ... jsObjectReferencecomes from a Fluent UI race:ListComponentBase.OnKeydownHandlerAsyncuses_jsModulebefore its import finishes (Fluent UI 4.14.4/4.14.5, per the worker).dev(1d3c1e2) has it: click in the search box on/activitiesand press Tab before the module loads, 5 of 5 runs crash (worker). Tabbing from the page top without a click: 0 of 5 ondev(Nerd).18dc0c1) crashes 3 of 3 on a plain early Tab from the top (Nerd). The worker's bisect says the cause is the new focusableh1(focus now starts at the top of the content, so Tab reaches the select sooner), not the accessible names orfocus.js.Not measured: how often real users hit this, and whether Fluent UI 5 changes it.
mwg-bender commentedon Oct 7, 2026
Deferred to the Fluent UI Blazor v5 migration (#81, milestone 0.8.0) by Woody's decision on 2026-10-07. Reading the v5.0.0 source (not run against EventManager):
ListComponentBaseand its C# keydown handler are gone,FluentSelectderives fromFluentListBase, and neither file references_jsModule. The select initializes with one JS call on first render. Re-test the early-Tab and Escape-before-load flows on/activitiesonce the migration lands. Not measured: any other early-interaction issue on v5.