Skip to content

DropdownMenu: tests pin a phone menu beside its trigger and no touch motion for a mouse open - #8089

Draft
vjeux wants to merge 7 commits into
meta:mainfrom
vjeux:uikit/c19-menu-placement
Draft

vjeux wants to merge 7 commits into
meta:mainfrom
vjeux:uikit/c19-menu-placement

Conversation

@vjeux

@vjeux vjeux commented Oct 24, 2026 •

Copy link
Copy Markdown
Contributor

Real-browser evidence from an earlier head (Chrome 156, 390 px, touch emulation, coarse pointer, the built Default story):

Trigger in the upper half Trigger in the lower half
The menu opens directly below its trigger, start-aligned, and doesn't cover it (trigger y 256, menu y 292). The same from the lower half (trigger y 656, menu y 692).

Re-applied onto current main as one commit on #8080. The mouse fix this pull request first carried moved into #8080, whose review asked for it there. What stays is the placement the owner decided here, with its tests. It leaves draft with #8080 and #8458.

No behavior change. On every screen, a phone's included, the popover menu opens beside its trigger at the layer's placement; nothing centers it over the trigger.

Why

A phone menu placed over its trigger hides the control that opened it. This pull request first proposed that placement; the engineering owner decided here that the menu stays beside its trigger, so the placement was removed.

What led to it

Comparing our menus with UIKit's on the iOS 26.2 simulator, then the owner's review of the proposal.

Options and tradeoffs

  • Center the menu over its trigger on a phone: closer to some UIKit menus, but it covers the trigger.
  • Keep the layer's placement on every screen (chosen): one rule, and the trigger stays visible.

Expected behavior and authority

The engineering owner's decision on this pull request: a phone menu keeps the layer's placement beside its trigger (the record amendment follows).

Evidence

  • On a compact touch screen, the menu opens at the layer's placement, not centered on its trigger or pinned to the viewport's sides, in jsdom and in real Chromium.
  • A caller's own placement is kept.

Scope

  • No intended public API, product behavior, visual direction, or policy change.
  • Product changes discovered during the work were removed or split.
  • Public text and artifacts contain no internal Meta context.

Testing

On the DropdownMenu "Default" story, in a phone-sized window with touch emulation, open it from the top and from the bottom of the screen: it opens below its trigger and never covers it.

Automated: the two compact-touch cases in DropdownMenu.test.tsx and DropdownMenuTouchPlacement (Chromium, WebKit). A [docs] changeset records the usage text.

Local gates at 7292457: the DropdownMenu, Layer, Popover, motion and hooks units pass (2,537 of 2,537) and the core type check. The full gates are running.

Stack: #8627 → #8078 and #8186 → #8080 → this PR. Review only this PR's change: vjeux/astryx@127f876...7292457

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Meta Open Source bot. needs:design-review Affects visuals — Design should review needs:spec-owner-review Current knowledge records await owner approval

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants