test(remote-react-components): keep the pointer on a hovered trigger while capturing - #2991
Closed
mfal wants to merge 1 commit into
Closed
test(remote-react-components): keep the pointer on a hovered trigger while capturing#2991mfal wants to merge 1 commit into
mfal wants to merge 1 commit into
Conversation
…while capturing The `Tooltip` scenario has kept the scheduled visual run red in both environments since 2026-08-27, and it is not a rendering regression: the `firefox-linux` baseline for `Tooltip - visible` shows the button with no tooltip. The three baselines beside it all show one. It is the only visual scenario that hovers before capturing, and `testScreenshot` then parks the pointer, un-hovering the trigger. react-aria keeps a tooltip painted for `closeDelay` — 500ms by default — so the capture normally still catches it. That is a race, not a guarantee: on a slow runner the frame comes out tooltip-less. The scenario passed by outrunning a timer it does not control. #2945 lost that race. It regenerated screenshots for a CodeBlock change, and because the `update-screenshots` label runs the whole suite with `--update` and then `git add -A`, it also committed the tooltip-less frame as this baseline — one stray file in an otherwise unrelated PR. Local and Remote share a baseline per description, which is why one bad file fails both. So stop parking the pointer for a scenario whose subject is a hover state. `keepPointerPosition` leaves it where the scenario put it, and a tooltip held open by a pointer that never leaves has no closing window at all. The trigger is then captured hovered, which is what a user actually sees with a tooltip open, so all four baselines change; the two `-darwin` ones are regenerated here. Also document the two traps behind this in the root AGENTS.md: the unscoped `update-screenshots` sweep, and `vitest run --update <file>` — where `--update` takes an optional value and swallows the positional filter, so the run updates every baseline and only the test count (354, not 2) gives it away. Both cost real time while diagnosing this, and the second nearly re-committed the very frames #2985 fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Coverage Report for ./packages/components/
File CoverageNo changed files found. |
Contributor
🚀 Preview DeploymentPreview environments are ready:
Images:
|
Member
Author
|
Folded into #2985. Both fixes have to land together: this branch needed The commit is carried over unchanged apart from the conflict resolution in |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The
Tooltipscenario has kept the scheduled visual run red in bothenvironments since 2026-08-27, and it is not a rendering regression. The
firefox-linuxbaseline forTooltip - visibleshows the button with notooltip — the three baselines beside it all show one:
Tooltip-visible-firefox-darwin.pngTooltip-visible-webkit-darwin.pngTooltip-visible-webkit-linux.pngTooltip-visible-firefox-linux.pngLocalandRemoteshare one baseline per description, which is why a singlebad file fails both.
Why the scenario was racy
It is the only visual scenario that hovers before capturing (checked across all
84 files).
testScreenshotthen parks the pointer, un-hovering the trigger.react-aria keeps a tooltip painted for
closeDelay— 500ms by default(
TOOLTIP_COOLDOWN,useTooltipTriggerState.mjs:17) — so the capture normallystill catches it. That is a race, not a guarantee: on a slow runner the frame
comes out tooltip-less. The scenario only ever passed by outrunning a timer it
does not control.
How the bad baseline got committed
git logon the file points at 6bf57c7 —fix(CodeBlock): balance the padding and unify the editor line colors(#2945). It regenerated 21baselines: CodeBlock, CodeEditor, Markdown — all legitimate — plus this one
Tooltip file, which has nothing to do with CodeBlock, and only the
firefox-linuxvariant of it.That is the
update-screenshotslabel working as built: it runspnpm test:visual --updateover the whole suite and thengit add -A, with noscoping to the PR's diff. #2945 happened to lose the tooltip race and committed
that frame as the new truth.
The fix
Stop parking the pointer for a scenario whose subject is a hover state.
keepPointerPositionleaves the pointer where the scenario put it, and a tooltipheld open by a pointer that never leaves has no closing window at all.
Restoring the pre-#2945 file would make the suite green again while leaving a
test that fails whenever a runner is slow, so it is not the fix here.
The trigger is now captured in its hover state — which is what a user actually
sees with a tooltip open — so all four baselines change. The two
-darwinones are regenerated in this PR.
main, which still has thefocus-ring bug test(remote-react-components): settle the tree before parking the pointer #2985 fixes.
update-screenshotshere, to regenerate the two-linuxbaselines. Applying it before test(remote-react-components): settle the tree before parking the pointer #2985 lands would run the whole suite with
--updatewhileList items (Remote)andList date range filter (Remote)are still failing, and commit those broken frames too — the exact mechanism
that produced this bug.
Until step 2 runs,
run-visual-testson this PR will fail on the two-linuxTooltip baselines. That is expected.
Verification
Tooltip.browser.test.tsx, firefoxTooltip.browser.test.tsx, webkit-darwinbaselinestest:compile, eslint, prettierAlso in here
Two rows in the root
AGENTS.mdCommon failures table, both verified whilediagnosing this:
update-screenshotssweep is unscoped — how fix(CodeBlock): balance the padding and unify the editor line colors #2945 corrupted a file itnever touched.
vitest run --update <file>updates every baseline.--updatetakes anoptional value, so it swallows the positional filter; the run reports the full
test count (354, not 2) and nothing else gives it away. Put the filter before
the flag, or use
--update=true. This one nearly re-committed the very framestest(remote-react-components): settle the tree before parking the pointer #2985 fixes — it rewrote them before I caught it in
git status.Checklist
pnpm lintis clean; browser tests pass in both browsersde-DEanden-US— n/a, no UI textintentional and explained above (
-linuxhalf pending, see Merge order)🤖 Generated with Claude Code