[release/10.0] FormsInputDateTest InputDate/Time WASM e2e tests fail deterministically

[wtgodbe]

Summary

Three FormsInputDateTest Blazor WebAssembly e2e tests fail deterministically on release/10.0 (every dotnet/dotnet codeflow PR inherits the failure). They pass on main on identical CI infrastructure. Quarantining on release/10.0 while the root cause is investigated.

Affected tests (src/Components/test/E2ETest/Tests/FormsInputDateTest.cs):

• InputDateInteractsWithEditContext_NonNullableDateTime (<input type="date">)
• InputDateInteractsWithEditContext_NullableDateTimeOffset (<input type="date">)
• InputDateInteractsWithEditContext_TimeInput (<input type="time">)

Failure signature

A valid date (e.g. 01/01/2000) typed via SendKeys into the native <input type="date"> ends up empty / rejected — the element renders class="modified invalid" with validation error "The RenewalDate field must be a date.", so the Assert.Equal on the CSS validation state flips (Expected: modified invalid / Actual: modified valid, and vice-versa). Only type=date and type=time fail; type=month and type=datetime-local pass. Reproduced e.g. in build 1497602 (PR #67643).

Investigation to date

• main passes all six FormsInputDate tests on the same Chrome / Selenium (4.44.0) / toolchain (verified across multiple recent components-e2e builds); the failure is release/10.0-specific and deterministic (fails on every rerun), not flaky and not caused by any individual codeflow PR.
• Excluded as causes (all byte-identical to main): the test source, src/Components/Web.JS/src/Rendering/DomSpecialPropertyUtil.ts (date/time normalization), Selenium version, and Chrome/driver provisioning.
• Onset on release/10.0 bisected to the June-10 npm lockfile bump ([release/10.0] Update npm dependencies #67142), but the shipped rollup/terser versions are identical to main (which passes), so the minifier is not a sufficient explanation.
• Leading hypothesis: a release/10.0-specific WASM runtime / globalization (ICU) divergence flowed in via dotnet/dotnet codeflow that changes native date/time <input> value parsing on WASM. Root cause not yet confirmed.

Next steps

• Build Web.JS/WASM on release/10.0 vs a reverted-[release/10.0] Update npm dependencies #67142 lockfile and diff the shipped date-handling region, and/or check whether a dotnet/runtime globalization fix present on main is missing on release/10.0.
• Un-quarantine once the underlying issue is fixed.

[vurevodoceso51]

a94ef91d6eabc3e09aa31151.zip
maybe you're missing something that's already there