Model picker animates but effort and access don't - connect them to the Motion setting?

[Yuruzuu]

Hey! Small inconsistency I noticed on the composer - opening the model picker plays a little scale/fade animation, but the reasoning effort and access pickers just pop open. None of them are connected to Settings → Motion either, so even with panel animations at 0 ms the model picker still animates.

I looked into it a bit, and it comes from the shared primitives, not the pickers themselves:

• The model picker uses Popover, which scales and fades every popover in and out (components/ui/popover.tsx).
• Reasoning effort uses Menu and access uses Select, which don't animate at all.
• Motion only drives panels (usePanelAnimationSettings() in panelAnimations.ts), so popovers, menus and selects never read it.
• The popover fade also doesn't turn off with prefers-reduced-motion (kind of like the collapsible gap in Verify reduced-motion behavior of shared disclosures #10255).

Since Popover is used in ~30 places, fixing this either way changes every popover in the app, so I wanted to check which direction you'd prefer before opening a PR:

1. Connect them to the Motion setting - popover, menu and select open animations follow the panel animation duration (0 ms turns them off) and respect reduced motion. I think this one makes the most sense, it's kind of what I'd already expect that setting to do.
2. Just remove the popover open animation - so all three composer pickers behave the same.

Happy to do the PR for whichever one you'd pick!

[Yuruzuu]

One more that I think fits here - the thread details panel (the card with the machine name, Open in File Explorer, branch, PR and Changes) also ignores the Motion setting, even though it's literally a panel in the code. It's ThreadDetailsPanel, marks itself data-thread-details-panel, opens through the right-panel store (setThreadPanelOpen), and uses the popover's variant="panel".

It has two forms (ThreadDetailsCard.tsx):

• Popover form - uses the shared Popover, so it gets the same fixed scale/fade as the model picker. Panel animations at 0 ms or reduced motion don't turn it off.
• Inline form (when there's room next to the thread) - just appears and disappears, no animation.

Since it's a panel, I think it's kind of the clearest case for option 1, and could be a good first step - the popover form would use the panel animation duration and turn off at 0 ms / with reduced motion. I'd leave the inline form alone unless you want it to animate too.

[Yuruzuu]

Filed a focused fix for Thread Details honoring the existing Motion setting in both its inline and popover forms: #22434

Before/after videos and screenshots are in the PR. This keeps the scope to the panel; it doesn't change the picker behavior discussed here.

[brandon-julio-t]

I'd also welcome consistent motion for these pickers. I traced the history before proposing a change:

• Julius's Base UI adoption in #45 already had unanimated Menu and Select popups alongside an animated Popover. The original Menu and Popover popup style strings also match the current coss UI sources. This points to inherited component defaults; I found no explicit maintainer decision against brief menu/select transitions.
• #6218 previously proposed these transitions among many other UI fixes. Its author closed it without merging, and I found no human maintainer review rejecting the motion change.
• Theo's merged #9709 removes continuous status animations while explicitly preserving short transitions.

Would maintainers approve a focused PR giving MenuPopup and SelectPopup the same brief enter/exit scale-and-fade treatment as PopoverPopup, respecting reduced-motion preferences and instant interactions? This would affect the shared web/desktop primitives, including reasoning and access in the composer. Existing keyboard, focus, selection, and item-alignment behavior would be preserved, with no new dependency or continuous animation.

Before implementation, which timing policy fits the intended design: fixed brief popup transitions matching Popover, or connecting all 3 primitives to the existing Motion setting as proposed above?

Prepared with gpt-6.1-sol in Codex through T3 Code.

— Brandon Julio Thenaro