fix(web): seal the seam between attached banners and the composer

[vitalyiegorov]

Closes #8546.

What Changed

At the join between an attached composer banner and the composer, one device-pixel row was painted by neither surface, so chat text behind it showed through crisp. The drawer's mask cut-off now bleeds one pixel past the seam so the drawer paints that row itself. One line in apps/web/src/components/chat/ComposerBanner.tsx (Surface, attached placement): transparent 0 calc(var(--chat-composer-attachment-overlap) - 1px), black calc(... - 1px). Reopened because #8733 removed this mask construction and #8734 restored it into ComposerBanner.tsx; the branch is rebased onto main @ 5b8445b (#7855, collapsed resting composer).

Why

Chromium drops the final device-pixel row of a filtered backdrop when the mask cut-off lands off the device-pixel grid, and the composer's surface begins exactly at that cut-off, so nothing covers the row. Anything painted at offset ≥ 0 (a border-top or inset shadow on the composer, or a separate strip) cannot reach it; the drawer's own mask can. The - 1px is absolute, not scaled with the 1rem overlap, because it repairs a device-pixel rounding artefact, not a layout distance; 2px is no better. Cost: the composer's glass covers the extra row, so the overlap is invisible (surface parity ≤7/255 worst case at 40% glass opacity, ≤4 at the 80% default, 0 at 100%).

UI Changes

Captured in the running web app with Playwright on main @ 5b8445b vs this commit, dark theme, DPR 1.25, viewport 1400×902, timeline scrolled so a bright line of chat text sits behind the join, the collapsed resting composer with a real attached notice ("This thread is snoozed"); only the commit differs.

Before vs after:

Seam magnified 4x, before vs after:

Per-device-row luminance at the cut-off (Rec. 709):

	before	after
cut-off row peak	75	30
neighbour mean	18.9	18.9
peak / neighbour ratio	3.97	1.59

Earlier captures (the original report, an intermediate before shot, and the full 224-configuration approach comparison) are in the details block below. At DPR 2 in a 1400-px window the banner bottom lands on an integral device pixel, so a Retina window of that size shows nothing either way — the leak needs an off-grid phase, which 125%/150% scaling hits constantly.

Verification

• Production Tailwind build (vp build, apps/web) emits the arbitrary value with valid spacing: mask-image: linear-gradient(to top, transparent 0 calc(var(--chat-composer-attachment-overlap) - 1px), black calc(var(--chat-composer-attachment-overlap) - 1px)), matching the sibling + 10px value on the same element.
• Sweeps on main @ 5b8445b, 208 configurations per DPR (viewport heights 900–907 × scroll offsets 100–200), cut-off derived from the DOM per configuration, leak = cut-off row peak ≥ 1.8× its neighbours' mean peak. Expanded composer with the offline banner: leaking configurations 80 / 78 / 0 at DPR 1.25 / 1.5 / 2 before; 0 genuine after (10 / 11 / 0 residuals at ratio 1.8–2.1, the band the never-leaking DPR-2 baseline also reaches). Collapsed resting composer with the snoozed notice: 101 / 163 / 1 before; crisp-text leaks (row at least 20/255 brighter than its brightest neighbour) 24 / 21 / 0 before and 0 / 0 / 0 after; a faint edge of about 28/255 can remain at some sub-pixel phases in the collapsed layout, five times dimmer than before, and the worst before-configurations drop from 3.9× to 1.3–1.7×.
• Rows above the cut-off are byte-identical before and after; rows below shift by ≤1/255.

Earlier captures and the full measurement history

Original report (macOS desktop app, "Resume with less context" banner):

Before, recaptured on main after #8734 moved this seam into ComposerBanner.tsx (dark theme, Retina, the unified activity banner reading "Monitoring"):

Expanded composer with the offline banner, before/after:

Magnified 4x, before and after:

device row	before mean / peak	after mean / peak
13	32.49 / 51.83	32.49 / 51.83
14 (cut-off)	58.33 / 157.35	35.83 / 57.83
15	28.23 / 69.00	25.51 / 51.14

Original 224-configuration approach comparison (7 device pixel ratios × 8 sub-pixel phases × ancestor transform × light/dark):

approach	leaking configs
main today	48
border-top, or box-shadow: inset 0 1px 0, on the composer	48
a strip built from the same tokens + backdrop-filter	30
mask bleed 1px	0

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — not applicable, nothing moves

Built with Claude Fable 5 in Claude Code.

---

Note

Low Risk
Single CSS mask tweak on chat banner styling with no auth, data, or API impact; only slightly shifts the rendered glass boundary at the attachment seam.

Overview
Fixes a one-pixel leak at the join between attached composer banners (e.g. snoozed/offline notices) and the composer glass, where chat text could show through unblurred on Chromium at non-integer DPR.

In ComposerBanner’s Surface pseudo-element, the mask gradient cutoff moves from --chat-composer-attachment-overlap to calc(... - 1px) so the banner’s backdrop-filter paints one device row past the seam; inline comments document the Chromium rounding behavior. Layout overlap and the dark-mode overlay gradient are unchanged—the extra row is covered by the composer’s own glass.

^{Reviewed by Cursor Bugbot for commit b3333fd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix ComposerBanner backdrop-filter seam at attachment boundary

Adjusts the surface pseudo-element's mask gradient in ComposerBanner.tsx so the opaque cutoff sits one pixel before the configured attachment overlap. This closes a Chromium backdrop-filter seam between the attached banner and the composer glass surface.

• Risk: the masked backdrop-filter region now extends one extra pixel toward the attachment seam, slightly changing the rendered boundary of attached and floating glass surfaces.

^{Macroscope summarized c39eede.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 94dd926e-6bf2-4e07-8c9b-7d4fb061ca95

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Warning

Your free Security trial is over. An organization admin can activate Security or dismiss this notice.

---

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This is a small, localized CSS visual fix for a one-pixel Chromium seam in attached composer banners. An unresolved finding identifies a plausible visible mismatch under configurable glass opacity and banner tint states, so the rendering behavior should receive human verification.

No code changes detected at b3333fd. Prior analysis still applies.

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

[macroscopeapp]

One finding on the new attachment-seal strip: its fill does not follow the same surface composition as the drawer it seals, so the sealed row can read as a band rather than a continuation of the drawer. Geometry, the shoulder-tab exclusion, and the --chat-composer-drawer-inset inheritance (via [data-chat-composer-form="true"]) all check out.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The strip paints the glass surface fully opaque and untinted, but the surface it is sealing is color-mix(in srgb, <surface> var(--glass-opacity), transparent) plus --chat-composer-attached-tint. Since bottom: calc(100% - 1px) puts 2 of the 3px on top of the drawer's own surface, the mismatch is visible there:

• --glass-opacity is a runtime user setting (40-100%, default 80; routes/__root.tsx:171). Every other composer/drawer surface derives from it, and the only other opaque paints of --chat-composer-glass-surface are inside @supports not (backdrop-filter) fallbacks. Below 100% the seal reads as a solid strip over translucent glass.
• The tint is dropped: the internal top drawer always sets data-variant="info"|"warning" (ChatComposer.tsx:2979) and banner-stack alerts set error/warning/success, each of which layers --chat-composer-attached-tint onto the drawer surface.

Consider composing the strip from the same tokens - the glass-opacity mix plus the drawer tint - and giving it its own backdrop-filter, so any row it loses at its own top edge lands on the drawer's already-blurred surface, keeping the opaque paint only for the @supports not fallback. The tint currently lives on the drawer element, so it needs hoisting to the shell (next to --chat-composer-attachment-seal-shade) for the strip to read it.

-      var(--chat-composer-glass-surface);
+      color-mix(in srgb, var(--chat-composer-glass-surface) var(--glass-opacity), transparent);
+    -webkit-backdrop-filter: blur(var(--glass-blur)) saturate(var(--glass-saturation));
+    backdrop-filter: blur(var(--glass-blur)) saturate(var(--glass-saturation));

^{Posted via Macroscope — UI Consistency}

Dismissing prior approval to re-evaluate cb2663d

[macroscopeapp]

One finding on the attachment seal: the repainted strip does not reproduce the glass composition of the surfaces it covers, so it becomes visible as an opaque band under non-default glass opacity and on tinted banner variants.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 36fe1b92229d214b56d0624f479409c7e2f677c6. Configure here.}

[vitalyiegorov]

Verified in the real app, not just the harness — same build, dark theme, DPR 2, with the actual ComposerBannerStack attached above the real composer and bright content behind it. The only difference between the two frames is the seal being disabled and enabled via an injected style; same page instance, same DOM, same clip box, no reload.

Per-row brightness across the clip (1448 device px wide), rows relative to the seam:

device row	before mean / peak	after mean / peak
0–5	identical	identical
6	21.1 / 68	20.1 / 68
7	24.4 / 73	20.1 / 73
8	38.6 / 76	20.1 / 76
9	39.2 / 70	20.1 / 68
10	42.1 / 77	20.0 / 29
11	41.4 / 77	20.0 / 29
12–19	identical	identical

Rows 10–11 are the leak: peak 77 against a ~60–68 surround, carrying crisp glyph tops. After the fix they read a flat 29. Exactly six device rows change — the 3 CSS px strip — and every row outside it is identical, so nothing else moved.

Every attached banner hits this seam: .chat-composer-drawer-surface is what ComposerBannerStack renders, and externalComposerDrawerAttached is composerBannerItems.length > 0.

[vitalyiegorov]

On the open visual-consistency question — configurable glass opacity and the alert tint variants across the overlap.

The bleed does not introduce a new surface. It extends the drawer's own masked surface one CSS px further down, into a strip the composer's surface already covers, so the two overlap there instead of leaving a row painted by neither. That means the only thing that can differ is a double composite of two semi-transparent surfaces over one CSS px.

Measured every state that can vary across the overlap — glass opacity 100 / 80 (default) / 40 %, light and dark, and the default / info / warning / error banner tints:

glass opacity	worst-case per-channel delta in the seam strip
100 %	0 / 255
80 % (default)	≤ 4 / 255
40 % (minimum)	≤ 7 / 255

Rows above the seam are bit-identical in every combination. Only the two device rows at the seam change, and there they go from showing chat text through the gap to the surface colour. The residual at 40 % is the expected double composite, and it lands strictly closer to the intended surface colour than the leak it replaces.

Worth stating plainly: this gives back 1 px of the 17 px the overlap lost in #8083. That is the cost of the fix, and I did not find a way to seal the seam without it — a border, an inset shadow, and a token-matched strip all still leaked, and an outset shadow sealed it but broke surface parity far worse (178–222 / 255).

[vitalyiegorov]

Closing — no longer reproducible on recent nightlies. If the seam leak resurfaces, the root-cause analysis and per-DPR measurements in this thread should spare the next person the diagnosis.

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.