讨论：半透明宿主背景使用 color(srgb …) 时配置页标签栏可能变黑 #239

使用了生成式人工智能创建了此内容，模型和推理等级为 GPT-6.1 Terra xhigh。

现象

在使用自定义毛玻璃补丁的 Linux DSH 桌面版中，插件详情页的「开始 / 模型 / 联网与工具 / 创作 / 手机与更多」标签栏出现纯黑背景，文字仍是亮色主题下的深色，导致难以阅读。页面其余部分呈亮色半透明效果。

环境：dsh-codex-subscription 3.2.6、DSH 0.2.2-rc.1，Linux Electron 桌面版；该桌面包有非 DSH 官方的自定义毛玻璃补丁。这不是在声称官方 DSH 默认构建必然复现。

打包项目背景与责任边界

这里的桌面包来自独立的 Nix 打包仓库 Mooling0602/nix-packages，不是 DeepSeek Harness 官方发行物，也不是本插件项目的组成部分。该仓库的 deepseek-harness-git 从 DSH 上游发布标签构建；deepseek-harness-desktop 则使用前者的构建结果和 nixpkgs 的 Electron，在 Linux 上装配上游桌面外壳。

该桌面包在构建时对 Electron 主进程 bundle 打下游补丁。为配合 Linux 合成器的毛玻璃，它让主窗口透明，并在桌面窗口的文档中注入 Linux 专用 CSS：清除部分不透明背景，同时将外层框架设置为主题底色的半透明 color-mix()；还有用于置顶区域的滚动淡出处理。具体实现和作用范围可见毛玻璃补丁脚本及说明文档。这不是插件注入的样式，也不应被视为官方 DSH 的默认配置。

因此这里有两个独立可调整的边界：下游打包项目决定是否及如何给宿主窗口应用透明效果；插件项目决定如何从宿主读取并绘制自己的标签栏背景。我们在维护前者，希望先与插件维护者讨论兼容方案，不预设问题应由任一方单独承担。

排查与可独立验证的机制

插件的 useBackdropOf 会向上查找第一个背景 alpha 不为零的祖先，通过正则提取 getComputedStyle(...).backgroundColor 的数字，并将前三个数字作为 0–255 通道写成内联 rgb(...)。它同时会丢弃 alpha。

桌面包的毛玻璃补丁使用 color-mix(in srgb, var(--dsw-alias-bg-base) 72%, transparent) 设置框架背景。Chromium 中，这类颜色可能序列化成 color(srgb 1 1 1 / 0.72)，通道是 0–1 而不是 0–255。

可以在 Chromium 的任意普通页面控制台运行下面的独立示例，不需要登录或账号数据：

const probe = document.createElement('div')
probe.style.background = 'color-mix(in srgb, rgb(255, 255, 255) 72%, transparent)'
document.body.append(probe)
const colour = getComputedStyle(probe).backgroundColor
const parts = colour.match(/[\d.]+/gu)
const pluginResult = `rgb(${parts[0]}, ${parts[1]}, ${parts[2]})`
console.log({ colour, pluginResult })
probe.remove()

本机 Chromium 输出：colour: "color(srgb 1 1 1 / 0.72)"，pluginResult: "rgb(1, 1, 1)"。也就是说，插件算法在遇到这种有效的 CSS 颜色序列化时，能把接近白色的背景错误地读成接近黑色。

**边界说明：**目前只独立验证了上述解析机制，还没有读取出问题的桌面窗口的实际祖先链、计算背景和标签栏内联样式，所以它与截图现象的因果关系仍需现场确认；也没有验证去掉补丁后的现场对照。

想请教维护者的修复边界

• 从兼容性角度看，插件是否适合避免假定计算颜色只能是 rgb()/rgba()，并正确处理现代 CSS 颜色格式与透明度？插件标签栏会主动复制宿主背景，因此类似背景也可能来自其他主题。
• 同时，自定义桌面包是否应避免让第三方控件继承需要特殊处理的透明背景，或为内容区域提供更明确的不透明背景？我们愿意在包侧配合调整。
• 对保持 sticky 标签栏在滚动时遮住下方内容，同时适配亮暗主题与透明桌面，是否有更符合项目设计的方案？

希望先讨论应由哪一侧修复、是否两侧都需要兼容，再决定具体改法。感谢！