Repository navigation
test(MultiSelector): the create-row contract reads what the live region exposed, not its live text - #9002
Conversation
…on exposed, not its live text The polite region clears itself 2 s after its last announcement, so a runner that reached its first read late found it empty. A MutationObserver now records each message the region exposes, and each check reads the latest one since its step began. Assertions unchanged. Test only. Original contract by @vjeux in #6829; residual race noted in review of #8987.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Recommended for approval: the three live-region checks now read what the polite region exposed, so its 2 s auto-clear can no longer fail a correct MultiSelector, and the expected messages are unchanged. With the first read delayed 2.5 s, the old reads get "" and fail while the new ones pass. One optional follow-up: recordPolite compares each text with the last recorded entry (line 51), so an identical re-announcement never enters the record despite the "every message" comments; comparing with the last observed text, or noting that repeats collapse, would close that gap.
[Automated review]
| document | ||
| .querySelector('[data-astryx-live-region="polite"]') | ||
| ?.textContent?.trim() ?? ''; | ||
| if (text !== '' && text !== exposed.at(-1)) { |
There was a problem hiding this comment.
Minor, optional: this compares with the last recorded entry, so a re-announcement of the same words (spec:AST-086 FR6: "A new occasion with the same words announces again") never enters the record. In this story 1 result is exposed after B, u and g but recorded once, so politeCount does not move across the g step. No current check depends on it. Comparing with the region's previously observed text (empty included) records repeats while still ignoring unrelated body mutations; otherwise the "Records every message" comment could say repeats collapse.
Maintainer impact
The create-row contract can still go red on a correct MultiSelector when a runner is slow. The polite live region clears itself 2 s after its last announcement, and the test reads the region's live text. A runner that reaches its first read more than 2 s after the announcement finds the region empty and fails, even though the right message was announced.
Intended invariant
The contract is unchanged. The region says
1 resultfor a partial match,Create "Urgent"when the create row is the whole result, andUrgent createdafter Enter. The newest message is the one asserted (spec:AST-086FR9 joins same-frame messages, as in #8987).Change
A MutationObserver now records every non-empty text the polite region exposes, in order, from before the first keystroke. Each check reads the latest message the region exposed since its step began, instead of the region's live text, so the auto-clear can no longer hide an announcement that was made. Test only: no product code and no Changeset.
Evidence
All runs were in Chromium against a CI-built Storybook, with Playwright 1.61.1.
Create "Urgent"check (a late runner), the current test fails 10/10 and reads"".Scope
Testing
pnpm exec playwright test packages/core/src/MultiSelector/CreateRow.a11y.chromium.spec.ts --project chromium --repeat-each=40 --fully-parallel, at normal load and under CPU saturation, plus the injected-stall variant before and after.prettier --checkandeslinton the file are clean.Credit: @vjeux wrote this contract in #6829, and @vjeux's review of #8987 pointed out this residual race.
Posted by Cindy's agent on her behalf.