[Bug] Model picker: row under a pinned provider heading shows through the translucent fill (0.2.2-rc.1)

[GandzyTM]

Environment: DSH 0.2.2-rc.1, Web GUI (desktop app build), macOS. Two provider groups in the picker (DeepSeek, opencode-go), current model deepseek-v4.1-flash (DeepSeek-V4.1-Flash).

What I see

Open the composer model picker and move the pointer over a lower, partially clipped model row (for example MiniMax-M3 under opencode-go). The list scrolls by about one row to reveal the hovered row. The current model row at the top (DeepSeek-V4.1-Flash) slides under the pinned provider heading DeepSeek. The heading keeps a 94%-opaque fill, so the row's label still shows through at roughly 6% and the heading plus the row read as duplicated, overlapping text.

The report is about the built-in picker (@deepseek-ai/dsh-client-ui-model-selection), not a third-party plugin; no plugin CSS in the affected profile overrides the heading token.

Pixel measurement from the screenshot above: the pinned heading band is about rgb(248, 249, 250), the ghost glyphs about rgb(232, 234, 234), roughly 6% of the label color. That matches the 0.94 alpha of --dsw-alias-menu-group-header-fill (#f8f9faf0 in light, #303136f0 in dark).

Screenshots

Reproduction with the shipped menu CSS and DOM in headless Chromium, before and after the proposed blur:

Steps to reproduce

1. Configure at least two providers with enough models that the menu scrolls, or use a window short enough to clip the card.
2. Keep the current model on the first row of the first provider group.
3. Open the model picker (trigger → Model).
4. Move the pointer over a model row lower in the list that is partially clipped at the bottom.
5. The picker scrolls the hovered row into view. The first row goes under the pinned heading, and its label shows through.

Expected

A pinned provider heading fully hides the rows passing beneath it. No ghost label, no duplicated provider/model text.

Traced cause

• packages/client/ui-primitives/src/MenuGroup.module.css: .heading[data-stuck] paints --dsw-alias-menu-group-header-fill, which is 94% opaque. The remaining 6% shows whatever row is behind it.
• packages/client/ui-model-selection/src/client/ModelSelect.tsx: the highlight effect calls scrollIntoView({ block: 'nearest' }) whenever activeModelIndex changes, including pointer hover (onMouseMove sets the highlighted index). Hovering a clipped row is therefore enough to scroll the list and slide the row above under the heading.

Possible directions

These are not upstream yet; external PRs are closed, so this is a design/fix discussion first. A fork branch implementing directions 1 and 3, with unit coverage, is linked in the first comment.

1. Keep the glass fill but blur the pinned heading (backdrop-filter: blur(8px)). Rows under it stay tinted but unreadable. I checked this against the shipped CSS and DOM in headless Chromium: the ghost disappears and the computed background-color stays rgba(248, 249, 250, 0.94). One caveat: backdrop-filter of translucent menus bleeds through the opaque composer card (0.2.2-rc.1) #12206 reports nested backdrop-filter/compositor bleed in an older Electron webview, so this direction should be verified there.
2. Make the stuck fill opaque in the theme token. Simplest, but loses the intended translucent band.
3. Do not scroll for pointer-driven highlights; keyboard and search highlights would still keep the active row in view. This is orthogonal and removes the specific trigger that produced the capture.

Ask

Is the translucent pinned heading meant to let the row show through, or should it occlude content? If it should occlude, which direction fits the design system? Once the direction is clear I can prepare a focused patch with unit and e2e coverage.

Related threads: #12206 (translucent menu backdrop bleed), #12536 (collapsible provider sections, same MenuGroup/ModelSelect files).

中文摘要

输入框模型选择器中，提供方标题吸顶且使用 94% 不透明填充。把鼠标移到下方被裁切的模型行（如 MiniMax-M3）时，列表会自动 scrollIntoView 滚动约一行，当前模型行（DeepSeek-V4.1-Flash）滑到吸顶标题下面，仍以约 6% 的透明度透出文字，看起来像标题重复或文字重叠。这是内置模型选择器，不是第三方插件。

像素测量：标题底色约 rgb(248, 249, 250)，透出的字约 rgb(232, 234, 234)，约 6%，与 #f8f9faf0 的 0.94 alpha 一致。

复现：配置多个提供方并让列表可滚动（或窗口较矮），当前模型位于首行；打开模型菜单；把鼠标移到下方被裁切的行；列表自动滚动，首行钻到吸顶标题下并透出。

可选方向：1）保留玻璃填充，给吸顶标题加 backdrop-filter: blur(8px)，让下方行不可读；2）把吸顶填充改成不透明；3）鼠标悬停不再自动滚动（键盘与搜索仍滚动）。已在 Chromium 用仓库真实 CSS/DOM 做过静态复现，方向 1 能消除重影且保持计算后的 rgba(248, 249, 250, 0.94) 不变；但 #12206 提到旧 Electron webview 的嵌套 backdrop-filter 问题，方向 1 需要在那种环境复核。

问题：吸顶标题的透出是刻意设计，还是应该遮住下方内容？确定方向后我可以补一个聚焦的 patch 与测试。

[GandzyTM]

Patch and verification are on a fork branch (external PRs are closed, so linking instead of opening one):

GandzyTM/deepseek-harness@master...fix/model-picker-sticky-heading

Changes

• packages/client/ui-primitives/src/MenuGroup.module.css: the stuck heading keeps its 94% fill and adds backdrop-filter: blur(8px), so rows under it cannot read through.
• packages/client/ui-model-selection/src/client/ModelSelect.tsx: pointer-driven highlights no longer scroll the catalog; keyboard and query highlights still keep the active row in view.
• Tests: a unit assertion that hover does not call scrollIntoView, and a stylesheet assertion that locks the blur. Both package READMEs document the behavior.

Verification (macOS, current master)

• pnpm exec vitest run packages/client/ui-model-selection/tests/model-select.client.spec.tsx -> 62/62. Reverting only ModelSelect.tsx makes exactly the two new assertions fail with one scrollIntoView({ block: 'nearest' }) call each, so the test catches the regression.
• The new menu-group-styles test fails on master and passes with the blur; menu-group.client.spec.tsx is 17/17.
• pnpm run test:gui -> 742 files, 13,091 tests passed.
• The pre-push typecheck passed. The before/after image above is the shipped CSS/DOM in headless Chromium; the computed background-color stays rgba(248, 249, 250, 0.94) and the computed backdrop-filter is blur(8px).

Not run here: the Playwright web e2e assertions in the branch (they need the built web scaffold); they only add computed-style checks for the same declarations.

Caveat from #12206: the heading now adds another backdrop-filter inside the menu surface. It renders correctly in current Chromium; an older Electron webview should be checked if that trade-off matters there.

[GandzyTM]

Resolved: the inaccessible list was not a core DSH bug.

Updating after isolating the original report with the reporter:

• At 14 px UI scale (no root zoom) the picker rises and the list fits and scrolls.
• At 18 px the card kept its pre-repair position and height, so the bottom rows stayed below the window. The cause is the local dsh-ui-scale plugin's popover repair, not the picker: when the web client clamps an over-tall card against the viewport edge, syncPanel's residual check can skip the repair.
• The plugin now falls back to the panel's aria-controls owner, caps the height to the free space above it, and applies the zoom factor. After reloading the client, the menu rises, is height-capped, and the remaining models are reachable by scrolling. Verified in a headless Chromium harness at zoom 1.2857: the previously overflowing card (bottom 545 in a 420 px viewport) now ends at 348 with --dsh-anchored-max-height: 261px; the reporter confirmed it works in the app.

The translucent heading bleed from the original capture is real but separate and cosmetic; it does not block the list. No core change is required for the reported blocker. The fork branch linked above stays as optional polish for that cosmetic case and is not needed to close this report.

Closing as resolved for the reported blocker. If the heading bleed is worth pursuing on its own, a narrower report can track it.