backdrop-filter of translucent menus bleeds through the opaque composer card (0.2.2-rc.1)

[peiyucn]

Environment: DSH 0.2.2-rc.1, Web UI, Edge/Chromium on Windows 11.

What I see

1. Open a session and start a turn that streams reasoning/thinking output.
2. Open the model picker / permission menu / FIM level menu (translucent MenuSurface) above the composer.
3. The transcript behind the opaque composer card is visible through the menu with a blurred look. During streaming, a rectangular block also flashes over the composer area.

The bleed-through alone is physically wrong: a translucent menu should blur the opaque card it overlaps, not the transcript behind that card.

Likely cause

• composerSeat received will-change: transform and a permanent z-index: 9 in [Bug] 0.1.7 空白新会话遇到 writer-held 时会静默换新会话，未发送的草稿随之“消失” #7591. The code comment says it "keeps descendant backdrop blur sampling the transcript".
• MenuSurface's material is a separate backdrop-filter layer portaled to body.
• Nested backdrop roots make the menu sample the transcript under the composer layer instead of the opaque card. The seat comment itself notes "the composer's backdrop blur is verified only in Chromium".

Expected

The menu samples its actual backdrop (the opaque card where they overlap); no transcript bleed, no flashing block.

Workarounds I tried (as a third-party theme plugin)

• Making the menu material opaque removes the menu-side flash, but loses the official translucent look.
• Lowering the composer's blur radius to ~2px makes the flash invisible, but degrades the frosted look.
• Removing will-change from the seat (restoring 0.2.1 compositing conditions) does not eliminate the flash.
• On 0.2.1 the seat had no will-change, and neither the bleed nor the flash appeared.

Ask

Could the menu's backdrop root be isolated from the transcript (for example a dedicated backdrop root for the composer card), or could the seat compositing hint be re-evaluated with backdrop-filter descendants in mind? Happy to provide a screen recording or a reduced repro if useful.

[peiyucn]

Update (environment correction): after more testing, this only reproduces in the VS Code built-in browser (Simple Browser / Electron webview), which ships an older Chromium than the desktop browser.

Reproduction matrix (same DSH 0.2.2-rc.1, same session):

Viewer	Chromium	Block flash over composer
VS Code built-in browser (Simple Browser)	older Electron/Chromium	reproduces (visible during thinking/streaming)
External Edge (desktop)	newer Chromium	no flash observed

The backdrop bleed-through described above (transcript visible through a translucent menu even though the composer card is opaque) was observed in the built-in viewer; the flash scales with the composer's backdrop-filter blur radius and disappears at ~2px, which points at the webview compositor reusing stale backdrop snapshots.

So this may be a webview/Chromium-version issue rather than a DSH rendering bug — but it is still worth confirming whether the composer seat compositing hint (will-change: transform) is intended to make descendant backdrop-filter layers sample across the composer. Happy to post the screen recording once I capture it in the built-in viewer.

[PerryLink]

0.2.2 added the menu animations that make this visible.

Two code facts frame it. The menu material is a backdrop-filter surface (packages/client/ui-primitives/src/MenuSurface.module.css:27) portalled to document.body, and 0.2.2 added data-menu-phase enter/dismiss animations whose own comment says opacity on the container would prevent the material from blurring the page (:51-65 in dsh-v0.2.2-rc.1; same file at fcc0ad46). The composer seat keeps will-change: transform on purpose, and its comment spells out why: without it the seat is only composited while it overlaps other composited content, and the hint "keeps descendant backdrop blur sampling the transcript" (ui-conversation/src/client/skeleton/ConversationRoot.module.css:529-541).

So the bleed is the documented trade-off of that compositing hint, not an accidental z-order bug: a body-level backdrop-filter that overlaps the seat resolves its backdrop against the page, and the transcript is what the seat is designed to blur.

The flash is the other half: the new enter/dismiss animation creates and then releases compositing layers (the same comment says so). A layer release under a virtual display adapter or mixed DPI can leave one frame where the window's own background is presented. On Windows that background is the Electron default white, because createWindow only sets backgroundColor on darwin (apps/desktop/src/main.ts:282-285). That is a separate bug from yours, but it explains why a dark theme shows a white frame rather than a dark one.

Your update that it only reproduces in the VS Code Simple Browser is the important part: the same markup and CSS in the app's Chromium do not do it, so this is an older-engine difference in nested backdrop roots, not a 0.2.2 regression you can fix from a theme plugin. If you want to test the isolation idea, the cheapest experiment is to drop will-change from the seat in DevTools and see whether the menu's backdrop changes; that tells you whether the seat's layer is the one being skipped.