fix(web): respect motion settings in the thread details panel#22434

Approvability

Verdict: Approved at d396869

Macroscope's review found this PR approvable — This is a narrowly scoped UI bug fix that applies existing motion settings to the thread details panel while leaving other popovers and product defaults unchanged. The shared Popover API addition is optional, so existing callers retain their behavior.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Merged current main (no rebase or force-push). The only conflict was ThreadDetailsCard.tsx, after #25731 and #25877 made the popover always mounted and added workspace focus. I kept main's structure and re-applied this PR's presence, inert, inline motion classes and popover duration on top. The net diff against main is unchanged from before. vp run check:changed passes.

Merged current main again (no rebase or force-push). The conflict was in ThreadDetailsCard.tsx with #26904 (choosing what the card shows). Both sides were additive: I kept #26904's contentKey measurement key and context menu, and this PR's presence and motion lines on top. The net diff against main is unchanged. vp run check:changed passes.

@coderabbitai Re the nitpick on ThreadDetailsCard.tsx:163 (inline exit and reopen browser coverage): declining. This is a motion fix, and the PR's recordings show the exit and reopen. Per docs/internals/testing.md, visual changes are proven with captures and should not get UI tests for nitpicks. The added lines also only connect the shared usePanelPresence hook and an inert prop. Presence retention belongs to that hook, not this card. There is no existing inline-closing case to extend either; the card's browser tests cover popover behavior.

@Yuruzuu Agreed. I checked docs/internals/testing.md and ThreadDetailsCard.tsx. The testing guidance excludes UI tests for visual nitpicks already shown by captures and requires testing shared logic at one layer. The card delegates presence retention to usePanelPresence and applies inert while closing.

I withdraw the browser-coverage nitpick. No additional card-level browser test is needed for this request.

_{You are interacting with an AI system.}

merged current main into this branch without rebasing or rewriting @Yuruzuu's commits. the original fix is already focused, so i kept its implementation: two files, +33/-1 against main. it reuses panel presence and motion settings, keeps closing inline content inert, and makes popover duration opt-in. find-bar position timing remains unchanged.

verification on a3b782a015ab7b9f805c8b95271e6eed0173bba5:

• blacksmith vp run check:changed 36dac688a17c6de1c6398e62d01546fb787c185b passed format, lint, both knip passes, affected typechecks, six thread-details browser tests, and react compiler checks.
• reproduced main removing the inline card immediately at 250 ms. chrome now verifies 250 ms in inline and popover modes, exit retention and inert state, rapid reopen, reduced motion, zero duration, navigation suppression, dark/narrow popover layout, and nearby terminal/right-panel toggles.
• both independent source reviewers approved this exact head with no findings. uploaded video playback and seeking checked in chrome.

unverified: native desktop/mobile and remote/relay sessions. github CI and preview workflows require maintainer approval before jobs can run (CI run 40989442190); reported checks alone do not clear that gate.

main before: thread details on the same project and thread

merged head after: thread details on the same project and thread

250 ms close, reopen, rapid reversal, then reduced-motion toggles

Verified in a real dev environment

verified unchanged head a3b782a015ab7b9f805c8b95271e6eed0173bba5 on this linux boat vm. reproduced first on github/main (32ecd71726) in a separate worktree, then ran the exact pr head. installed dependencies with vp i and used one background dev server at a time, with isolated task data. drove the real web app with the repository's playwright and /usr/bin/google-chrome.

created projects pointing at real git repositories and threads through the app. submitted real codex gpt-6.1-sol turns through the composer and saw completed replies. the matching captures use the same task-created project, thread, prompt, and response. no mocks, fixtures, or replay provider.

selected 250 ms through settings → appearance → advanced → panel animations:

also exercised thread switching during close, returning to the original thread, the dark 1000×900 popover, the right-panel surface picker, and terminal drawer open/close. find-in-thread found both matching messages and retained its separate 150 ms layout slide. main's initial two replies became visible after reload; fresh pr turns rendered their replies live.

blacksmith vp run check:changed 36dac688a17c6de1c6398e62d01546fb787c185b passed format, lint, both knip passes, affected typechecks, all six existing thread-details browser tests, and react compiler checks. worker setup needed the pr's shallow history and chromium installed before the successful run. no source changes or pushes were needed.

inspected the full-size captures and recordings. uploaded video playback and seeking were checked in t3's browser. the inline animations below preserve the recordings' dimensions and timing. git.cafe renders external media as links; github renders these animated copies inline. the before clip shows immediate removal; the after clip shows 250 ms close/open, rapid reversal, then reduced-motion toggles.

main before: real codex response and inline thread details at 1600×1000

pr after: matching project, thread, response, and inline thread details

main before: card disappears immediately with 250 ms selected

pr after: animated close/open, rapid reopen, then reduced-motion toggles

Not verified

native electron shell, macos/windows, native ios/android, remote/relay/tunnel connections, and other providers were not exercised on this linux web setup. the change is in the shared web/desktop components; mobile has separate ui. no claims about those untested paths or measured performance.