fix(web-components): defer fallback custom-state attributes

[Sylvester Kaczmarek (sylvesterkaczmarek)]

Previous Behavior

The attribute fallback for CSS custom states mutates the host during construction. With :state() unsupported, document.createElement('fluent-tablist') fails because the constructor adds state--horizontal before returning.

New Behavior

Queue fallback attribute changes through FAST's DOM update queue. This keeps construction attribute-free and preserves toggle/swap ordering, including state changes before connection. The native ElementInternals.states path is unchanged.

Adds three browser regressions and a patch change file. This fixes the shared web-components implementation; Blazor will need the resulting package release.

Validation

• All three new fallback regressions fail before the fix and pass afterward.
• Chromium tablist suite: 24 passed, 1 existing failure. The same disabled-tab selection test also fails on pristine upstream source (21 passed, 1 failed), without either code or test changes.
• Checkbox, divider, and progress-bar suites: 46 passed.
• Library and test TypeScript checks, plus Prettier checks: passed.

Tests used the repository's FAST browser harness through focused Nx targets, Playwright 1.56.1 and cached Chromium build 1208. Firefox, WebKit, and the full monorepo suite were not run.

Related Issue

Addresses microsoft/fluentui-blazor#5262.

The consumer issue was closed during implementation because older Chrome versions are outside Blazor's support policy. The maintainer nevertheless explicitly welcomed a contribution fixing the fallback: microsoft/fluentui-blazor#5262 (comment).

[Kryštof Žáček (KrystofZacek)]

Very well. Thanks!

[Kryštof Žáček (KrystofZacek)]

Just a remark: isn't textarea affected by the same problem too?

[Sylvester Kaczmarek (sylvesterkaczmarek)]

Yes. textarea uses the same shared fallback: autoResizeChanged() calls toggleState(), and resizeChanged() calls swapStates()/toggleState() during initialization. This PR fixes the shared element-internals fallback, so textarea is covered as well; tablist is just the regression reproducer used here.

[Sylvester Kaczmarek (sylvesterkaczmarek)]

Following up after the earlier inactivity. I have refreshed this shared fallback fix onto current master; it is now 0 behind and mergeable, with the prior textarea/tablist discussion already addressed and no unresolved review threads. Ready for review when convenient.

[Sylvester Kaczmarek (sylvesterkaczmarek)]

Chris Holt (@chrisdholt) Could you take another look at the shared fallback fix? The earlier tablist/textarea questions are addressed; GitHub Actions still needs maintainer approval.

[Chris Holt (chrisdholt)]

Chris Holt (@chrisdholt) Could you take another look at the shared fallback fix? The earlier tablist/textarea questions are addressed; GitHub Actions still needs maintainer approval.

Yes - looking to test #36808 with Blazor before it goes in and then we can look at how this plays with existing known hydration paths.

[Sylvester Kaczmarek (sylvesterkaczmarek)]

I tested #36722 together with #36808 in an isolated branch (no changes to either PR). The branches merge cleanly, the web-components TypeScript compile passes, all 3 Chromium client-side custom-state fallback regressions pass, and 96 Chromium SSR-mode tests across tablist, textarea, and checkbox pass. This covers the web-component harness only; it does not replace your planned Blazor hydration test.

[Chris Holt (chrisdholt)]

I tested #36722 together with #36808 in an isolated branch (no changes to either PR). The branches merge cleanly, the web-components TypeScript compile passes, all 3 Chromium client-side custom-state fallback regressions pass, and 96 Chromium SSR-mode tests across tablist, textarea, and checkbox pass. This covers the web-component harness only; it does not replace your planned Blazor hydration test.

Awesome, appreciate this! I have one separate test to do for a specific hydration situation but at a glance this is super clear and focused. Thanks @sylvesterkaczmare!