cmux NEXT: session hover cards and the What's New popover are glass again, not solid

Merged
TE
15d ago
+143-9

Leo on his nightly, 2026-10-21: "WHY IS THIS SOLID COLOR AGAIN". The What's New popover beside the Update Ready card and the sidebar's session hover cards showed as solid cards. They should be glass in the shared material.

Cause

All of these show in one window, the app's hover card window (HoverCardPanel): the workspace/session cards, the tab cards and the Update Ready card's highlights popover ("1 Switch fonts in a step…", "See all changes →"), which presentOwned puts in that same card.

  • #21785 (Leo, 2026-10-19) made every text overlay themed Liquid Glass, after Leo said of the session hover card on 2026-10-19: "it's solid gray?"
  • ccde782cb51 ("floating cards are mostly opaque with a clear rim (one CardMaterial)", lawrencecchen, 2026-10-20, a direct push to feat-cmux-next with no PR) put the CardMaterial fill under the content of every theme-tone Glass.makeOverlayPanel, at 90% or more opacity: the solid popup surface. The hover card window was included, so the session cards and the What's New popover became solid again. That is the regression.
  • The Update Ready card (CardSurfaceView) was already the shared neutral glass veil (FloatingGlassStyle.card, 22% dark / 45% light) since 17228e100b1, and it still is. This PR doesn't change it; the new test guards it.

Change

  • Glass.makeOverlayPanel takes cardFill (default true). The palette, popovers and find and prompt bars keep the card fill Lawrence asked for.
  • HoverCardPanel and the hover card gallery host pass cardFill: false. They draw the shared themed overlay glass alone: Liquid Glass tinted with Palette.glassTint × glass.overlayTintStrength, or the behind-window blur before macOS 26.
  • Reduce Transparency stays the solid popup surface.
  • Only the material changes. The card's position and anchoring are untouched, so this doesn't collide with the sibling hover card alignment fix.

Invariant

FloatingSurfacesStayGlassTests (CmuxNextDesignTests, run by the swift test job when CmuxNextDesign changes) fails when:

  • the hover card window's surface is a CardMaterial card again, or any fill between its material and its content is denser than the shared glass (the FloatingGlassStyle veils and the themed overlay tint). It checks both Liquid Glass and the pre-26 blur, in a light and a dark theme;
  • the hover card gallery host stops matching;
  • the Update Ready card's CardSurfaceView stops being the shared veil.

A control case proves the check catches the 90% card fill. The source-level no-opaque-glass ast-grep rule (#23366) didn't catch this regression because the fill sat on a separate view laid over the glass. This test checks the fill values the views actually draw.

Changelog

  • Fixed: Session hover cards and the Update Ready card's What's New popover are glass again instead of a solid card.

Observed / Not run

  • On the fleet (cmux-ci step 94e713e351661d3c61bcf815, aws-m4pro-4, Xcode 26.6) at head 763689a704891daf379ac42928976ed721188029, package-test-lane.sh suite Packages/macOS/CmuxNext built CmuxNext with its tests, so the Swift compiles. These suites ran and passed: FloatingSurfacesStayGlassTests (new), HoverCardGlassTests, CardMaterialLegibilityTests, FloatingGlassStyleTests, WorkspaceHoverCardSurfaceTests and UpdateCardHoverParityTests.
  • Not run: the new test's red at the base. At the base, HoverCardPanel().glass.isCard is true and its tint view fills at the CardMaterial opacity (≥ 0.9), which is what theCardFillTheHoverCardDropsIsSolid asserts is caught.
  • No capture: the fleet capture client isn't installed on this host (cmux-ci capture needs an HQ checkout, and #2713 isn't deployed). The change is the hover card's fill alpha, and the tests above check it on both materials. A light/dark capture will follow.

Agent session: cosmic-gray

🤖 Generated with Claude Code