DropdownMenu / MoreMenu: first item looks selected when opened by pointer (no way to opt out of initial focus)

[ShashankSirmour]

Summary

When a DropdownMenu (or MoreMenu) is opened with a mouse click, focus moves to the first enabled item and its focus ring renders. To users it reads as "this item is already selected" — several people on my team have asked whether the first action was pre-chosen or somehow highlighted by mistake.

For keyboard opens this is exactly right and shouldn't change. The problem is only that pointer opens get the same treatment, and there's no prop to opt out.

What I ran into

A table row actions menu — Edit details / Edit permissions / Delete role:

<DropdownMenu
  button={{ label: `Actions for ${role.name}`, icon: <MoreVertical />, isIconOnly: true, variant: 'ghost' }}
  hasChevron={false}
>
  <DropdownMenuItem icon={Pencil} label="Edit details" onClick={...} />
  <DropdownMenuItem icon={SlidersHorizontal} label="Edit permissions" onClick={...} />
  <DropdownMenuItem icon={<Trash2 />} label={<span>Delete role</span>} onClick={...} />
</DropdownMenu>

Click the three-dot trigger → "Edit details" is visibly highlighted before the pointer goes anywhere near it. It also shifts depending on state: when the first item is isDisabled, the highlight lands on whichever item is first enabled, so the "selected" row appears to move around between rows in the same table.

Same behavior via the items data prop and via MoreMenu, so it looks like it's in the shared keyboard/focus path rather than either wrapper.

Why it's awkward to work around

DropdownMenuProps exposes button, isMenuOpen, onOpenChange, menuWidth, onClick, hasChevron, placement, data-testid — nothing focus-related. DropdownMenuItemProps has icon, label, description, onClick, isDisabled, endContent. So there's no supported way to say "don't focus anything until the user arrows in", short of CSS against internals, which I'd rather not ship.

Proposals (either would solve it)

A. Match focus behavior to the input modality (my preference — no new API, fixes it everywhere at once)
Focus the first item when the menu is opened via keyboard (Enter / Space / ArrowDown on the trigger), but on pointer open leave focus on the menu container so nothing is visually highlighted. First ArrowDown then moves to item 1. This is what most menu implementations do, and it pairs naturally with :focus-visible.

B. Add an opt-out prop

<DropdownMenu hasInitialFocus={false}> ... </DropdownMenu>

Defaults to true so nothing changes for existing users.

If the highlight is intended to be :focus-visible-driven already, then this may just be a bug where the ring shows on programmatic focus after a pointer open.

Acceptance criteria

• Opening by mouse click shows no item highlighted; the menu is still keyboard-operable and ArrowDown moves to the first item.
• Opening by keyboard still focuses the first enabled item immediately (unchanged).
• Behavior is the same for DropdownMenu items-array mode, DropdownMenu compound mode, and MoreMenu.
• Disabled leading items are still skipped when focus does move.
• Screen reader announcement of the menu and its items is unchanged.

[HelloOjasMutreja]

Proposal: Option A, and there's already a half-built seam for it

Hi @cixzhang, happy to take this. Read through the actual open/focus code in DropdownMenu.tsx before proposing anything.

What's there today

handleButtonClick (pointer) and handleButtonKeyDown (keyboard) both call the same openAndFocus(), which unconditionally does popover.show() then focusFirst() on the next frame (DropdownMenu.tsx:340-343). No branch on input modality anywhere in that path.

For the controlled (isMenuOpen) mode, there's a second, separate focusFirst() call in the sync effect (DropdownMenu.tsx:296-305) that fires on any controlledIsOpen transition to true, pointer or keyboard, so a fix needs to cover both the uncontrolled and controlled paths.

One more thing worth flagging: there's already a shouldFocusOnOpenRef (DropdownMenu.tsx:229) that reads exactly like unfinished scaffolding for this — it's set up to gate a focus-on-open call, checked once in handleLayerShow, but nothing currently sets it to true, so it's dead in practice. Wiring it up (rather than adding new state) seems like the intended shape here already.

Proposed change (Option A, no new prop)

• handleButtonKeyDown: set shouldFocusOnOpenRef.current = true before calling openAndFocus().
• handleButtonClick: leave it false (pointer path).
• openAndFocus(): only call focusFirst() if the ref is true; otherwise just show the popover and leave focus on the trigger/container, so nothing reads as pre-selected.
• The controlled-mode effect (DropdownMenu.tsx:296-305): same ref check before its focusFirst() call, so isMenuOpen-controlled callers get the same behavior.
• ArrowDown from an unfocused-but-open menu still lands on the first item via the existing useListFocus navigation, so the "still keyboard-operable" acceptance criterion holds without extra code.
• MoreMenu wraps the same DropdownMenu internals, so this should cover it for free — I'll verify with a test rather than assume.

No new prop, since Option A fixes it uniformly per your/the issue's stated preference. Let me know if this lines up and I'll open a draft PR.