FA-32138 / Keyboard interactions / Member archive
Asynchronous keyboard capture grant lifecycle: Explicit unlock leaves pending or already granted key capture active · case 03
The event trace violates the release all rule and produces incorrect keyboard state or command output.
Case contract
Events [kind,id,keys]. Initial window is focused. Request replaces pending id and deduplicated requested keys while focused. Grant applies only to current pending id while focused, filters Escape from captured keys, replaces active grant and clears pending. Deny clears only matching pending. Blur clears pending and active; focus restores eligibility; release clears both. Return focused flag, pending [id,keys] or None and active keys. Inputs are finite ordered event traces; return the stated deterministic state. Batch entries are independent. N varies the number of independent input transactions.
Why this case matters
Controlled keyboard event processing model for debugging application event logic.
One recorded failure
Sample boundary fixtureThis sample comes from the broken implementation of a controlled reproducer.
| Boundary fixture | Actual | Expected | Outcome |
|---|---|---|---|
| keyboard-lock scenario 8 | [[true, null, ["A"]], [true, null, ["A"]], [true, null, ["A"]]] | [[true, null, []], [true, null, []], [true, null, []]] | Failed |
MEMBER ARCHIVE
The complete case is available to members.
This record includes three runnable implementations, regression fixtures, execution results, and source hashes.
Member access is invitation-based. Sign in with your invited account to inspect the sources.
Sign in to the archive ↗