Repository navigation
docs(DropdownMenu): FR22 notes the still-mouse shield gap - #10148
Conversation
`spec:AST-094` records that after a finger, the first press of a mouse that has not moved since lands on the entering presentation's shield and does nothing, where FR35 keeps today's behavior for a mouse. meta#8458 brought DropdownMenu under that, and FR22 now notes it as an implementation gap.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
github-actions
Bot
added
the
needs:spec-owner-review
|
/approve-spec a291c55 |
github-actions
Bot
removed
the
needs:spec-owner-review
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Changes requested: the new FR22 note is accurate and matches the touch-presentations spec, but the record's own current-state summary does not list it yet.
- Add the still-mouse gap to the record's Current-state impact list (
docs/specs/components/DropdownMenu/DropdownMenu.spec.md, lines 369–385) and to the gap list in the Compatibility/readiness row (line 48), as the record does for its FR8, FR21, FR3 and FR17 gaps, so that summary no longer presents FR22's mouse clause as met.
The note itself checks out against the shared input hold: after a finger, a mouse press that comes before any mouse move lands on the entering menu's shield.
[Automated review]
| | FR20 | With `header` or `footer` on a sub-menu (`DropdownMenuSubMenu`), its surface is a modal dialog named by its row (AR7), holding the header, the sub-menu's `role="menu"` (rows only), then the footer. It sits in a host `DropdownMenu` renders beside its menu, never inside a menu; under a root with no such host (`ContextMenu`) the sub-menu shows its rows alone. On a fine pointer the dialog is the flyout; on a compact touch display, the drilled-in view, which replaces the root's menu and regions until popped. A region keeps its own keys and presses. The rows are one Tab stop: Tab and Shift+Tab walk the header's controls, the rows, then the footer's, and wrap; from a deeper flyout, that flyout closes and the walk goes on from the rows. An open lands as for any sub-menu (FR11, FR12), not on a region. Escape in the dialog, outside an IME composition and unless a control there handled it, returns focus to the row and leaves the root open. A pointer leaving the flyout keeps it open until focus leaves, and it closes with the flyout holding its row. Without either prop nothing changes. | Current behavior; FR15; AR5 | | ||
| | FR21 | Under a finger, in the touch modes (`presentation` not pinned to `'popover'`), the pointer menu MUST grow out of the Trigger button on the theme's entrance duration and easing tokens and collapse back into it on the theme's exit duration and easing (`spec:AST-094` FR7, FR31, FR45), and MUST close as a pan that starts outside it begins (FR32); a pinned `'popover'` keeps the layer's own entrance. A pan dismissal is the menu's own close: focus that was in the menu returns to the Trigger button, whose `aria-expanded` turns false. A mouse keeps the layer's own entrance and exit. Implementation gap: the menu keeps the layer's own entrance and exit under a finger too, and has no pan-outside dismissal of its own. | `spec:AST-094` FR31, FR32; `family:overlay-dismissal` AV6 | | ||
| | FR22 | Under a finger, in the touch modes, where the primary pointer is coarse (a phone or a tablet), a tap or a drag that lands while the pointer menu enters MUST reach nothing: it closes nothing, scrolls nothing, moves no focus and clicks nothing (`spec:AST-094` FR35). The finger that opened the menu still picks the row it lifts on (FR8). Keys and assistive technology stay live. A mouse, a pinned `'popover'` and a finger where the primary pointer is fine (a touchscreen laptop) hold nothing, as for `component:Drawer`. | `spec:AST-094` FR35; `architecture:layer-runtime` | | ||
| | FR22 | Under a finger, in the touch modes, where the primary pointer is coarse (a phone or a tablet), a tap or a drag that lands while the pointer menu enters MUST reach nothing: it closes nothing, scrolls nothing, moves no focus and clicks nothing (`spec:AST-094` FR35). The finger that opened the menu still picks the row it lifts on (FR8). Keys and assistive technology stay live. A mouse, a pinned `'popover'` and a finger where the primary pointer is fine (a touchscreen laptop) hold nothing, as for `component:Drawer`. Implementation gap: after a finger, a still mouse's first press lands on the entering menu's shield and does nothing (`spec:AST-094` FR35). | `spec:AST-094` FR35; `architecture:layer-runtime` | |
There was a problem hiding this comment.
This gap also needs a bullet under Current-state impact (lines 369–385) and a mention in the Compatibility/readiness row (line 48), as the record does for its FR8, FR21, FR3 and FR17 gaps.
The record's Current-state impact gains the still-mouse gap that FR22 notes, and the readiness row of the summary table names it, so the summary no longer reads FR22's mouse clause as met.
github-actions
Bot
added
the
needs:spec-owner-review
|
/approve-spec a2c6018 |
github-actions
Bot
removed
the
needs:spec-owner-review
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet.
The FR22 implementation-gap note matches the touch-presentations spec's current record for DropdownMenu, and the still-mouse gap is now listed under Current-state impact and in the Compatibility/readiness row, as the earlier review asked.
- Next step: mark the pull request ready for review, and a maintainer adds the
ci:runlabel so CI runs on this fork branch.
[Automated review]
The Current-state impact entry for the still-mouse gap now reads as a known defect against FR22's touch-only scope, with its fix: a press whose own pointerType is mouse passes the shield.
github-actions
Bot
added
the
needs:spec-owner-review
|
/approve-spec 27a9fb9 |
github-actions
Bot
removed
the
needs:spec-owner-review
There was a problem hiding this comment.
Changes requested: the still-mouse gap itself matches the touch-presentations spec, but the latest commit adds a cause and a planned fix to the record's Current-state impact entry.
- In
docs/specs/components/DropdownMenu/DropdownMenu.spec.mdlines 379–380, remove "(a side effect of the press-ignore rule); the fix lets a press whose own pointerType is mouse pass the shield", because a record describes the system in the present tense without implementation steps (architecture:knowledge-contracts, rubric item R1), no record defines a "press-ignore rule", and the fix does not exist yet.
After that edit, update R1 in the writing rubric results; the spec gate then needs an engineering owner's /approve-spec <full head SHA> for the new head.
[Automated review]
| against FR22's touch-only scope (a side effect of the press-ignore rule); the | ||
| fix lets a press whose own pointerType is mouse pass the shield. |
There was a problem hiding this comment.
This cause and fix describe the implementation and a planned change, not the system: architecture:knowledge-contracts asks a record to describe the system in the present tense without implementation steps (rubric item R1), and no record defines a "press-ignore rule". Ending the bullet at "…against FR22's touch-only scope." keeps the gap and drops both.
The Current-state impact entry keeps the known defect against FR22's touch-only scope, without a cause or a planned change.
github-actions
Bot
added
the
needs:spec-owner-review
|
/approve-spec 2f01337 |
github-actions
Bot
removed
the
needs:spec-owner-review
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. It starts once the pull request is marked ready for review and a maintainer adds the ci:run label.
The FR22 implementation-gap note, its Current-state impact entry and the readiness-row mention match the touch-presentations spec's current record of DropdownMenu's still-mouse gap, and the cause and planned-fix wording from the previous round is gone.
- Non-blocking: #8870 adds a different FR22 row (Tab closing every open level) to this record from an older base, so one of the two will need another number when it rebases.
[Automated review]
cixzhang
added
the
ci:run
Exact decision needed
Whether
component:DropdownMenurecords the still-mouse behavior thatspec:AST-094records for DropdownMenu.Existing authority searched
spec:AST-094's Current-state impact, which fix(DropdownMenu): on a phone or a tablet, a tap while the menu enters is ignored, as on iOS #8458 extended to DropdownMenu: after a finger, the first press of a mouse that has not moved since lands on the entering presentation's shield and does nothing, where FR35 keeps today's behavior for a mouse (DEC-16).component:DropdownMenuFR22, where a mouse holds nothing.Layer/inputHold.ts): only a mouse that moves with no button down lowers the shields.DropdownMenu.spec.md: none edits these lines.Decision
spec:AST-094FR35)."Rejected alternatives
spec:AST-094records the behavior as a deviation, since FR35 keeps today's behavior for a mouse (DEC-16).Claim scope and non-goals
Only a still mouse's first press after a finger, during that entrance. How a mouse opens the menu, the coarse-pointer scope and the timing are unchanged.
Evidence and implementation relationship
No code change: since #8458, DropdownMenu holds its entrance through the shared input hold, which behaves this way today.
Writing rubric results
Scope
Validation
pnpm check:knowledgegit diff --checkFR22's row keeps its width, so no other row of the table changes.