Repository navigation
cmux-next tests: the first tooltip's fade is read with the surface clock held (macOS 27 lane) - #20742
Conversation
The macOS 27 report-only lane fails theFirstTooltipFadesInRisingAndAWarmNeighborsIsThereAtOnce at the opacity read with no detail. The failure now names what the panel and its layer hold (shown, visible, keys, the rise's age, motion policy), to tell a timing or environment gap from a product bug. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Not verified: macOS jobs did not run: compile and app tests were skipped on CI passes on Written by |
|
Bead |
This comment has been minimized.
This comment has been minimized.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…delay (red) The macOS 27 lane runs every suite in one process, so the test can come back to read the fade after it has finished and Core Animation has removed it: the lane failed at the opacity read once (run 38638271559) and passed on the same mini and code an hour later (run 38647037583). Waiting 300 ms after the show, longer than the 120 ms fade, makes that deterministic. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e test reads them The tooltip tests read the fade the first tooltip starts after async waits. On a loaded host (the macOS 27 lane runs every suite in one process) the 120 ms fade can finish and be removed before the read: no product bug, the tooltip fades. The surface layer's clock now stands still in the test (speed 0), as the hover delay does on the manual clock, so the read sees the fade however late it comes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
… the tooltip read On the one-process GitHub lane another suite can set or clear the process-global Motion.reduceMotionOverride while a tooltip test awaits the hover delay (underReduceMotionTheTooltipFadesWithNoRise saw a rise, run 38662157909). The fade's length tells which gate the tooltip read (Reduce Motion caps it at one crossfade); the rise must follow it, and a read that differs from the test's own override needs a change notification from another suite. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d; pin live resize Review: a change by another suite after the show (the 300 ms wait) could excuse a tooltip that ignored Reduce Motion. The watch now stops at the show. The first test also pins Motion.liveResizeOverride off, since another suite's live resize drops the rise. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TooltipSurfaceTests.theFirstTooltipFadesInRisingAndAWarmNeighborsIsThereAtOnce(from #20528) failed on the macOS 27 report-only lane at the opacity read: "the first tooltip did not fade in" (run 38638271559). #20725 stopped that lane from exiting early, which is why the failure only showed up now.Cause: the environment, not the product. The tooltip does fade in. The failure has two sources, both on the GitHub swift test lane, which runs every suite in one process on one main actor:
layer.animation(forKey: "opacity")after async waits. On a loaded host the 120 ms fade has finished, and Core Animation has removed it, before the test gets there. The same mini and code passed an hour later (run 38647037583).Motion.reduceMotionOverrideis process-global, so another suite can set or clear it while a tooltip test waits out the hover delay. Fixing (1) exposed this: in run 38662157909 the Reduce Motion test saw a rise that the tooltip legitimately added after another suite had turned Reduce Motion off.Fix (test only):
speedto 0, so its animations hold still, the same way the hover delay holds on the manual clock. The test reads the fade the tooltip actually starts, however late it gets there.reduceMotionDidChangebefore the show.Motion.liveResizeOverrideoff, because a live resize drops the rise.All the existing assertions are kept.
Testing
All runs use
cmux-ci run --class light --label cmux --script scripts/ci/run-swift-testing-suites.sh --arg Packages/macOS/CmuxNext.Red (
abf6fec,restwaits 300 ms after the show):shown Back, visible true, same layer true, keys [], opacity 1.0.Green:
d3a2fc3: step bebc7978ca8e7eae02753523 on aws-m4pro-8.fa7fd95: step 3ac4cc4f6294660babfc59c1 on aws-m4pro-9.Not counted or not this PR:
SidebarInsertWhileDisplayAsleepTestsis a base red in every one of those steps.GitHub swift test lane:
full-ciis added only to runcmux-next swift teston the GUI mini. Since #20543, PRs run swift test only underfull-ci. The other full-ci lanes run too, but this PR is not checking them.Not fixed here:
theSurfaceIsFrostedGlassOrOpaqueUnderReduceTransparencysometimes readsshadowOpacity0 on that lane. It already did on base (run 38638271559), and it passes on the fleet.Changelog
none
🤖 Generated with Claude Code