[Feature] Windows 桌面版支持 Ctrl+= / Ctrl+- 页面缩放（补回 zoomIn / zoomOut / resetZoom）

[happytong1]

环境

• App：DeepSeek Harness 桌面版（Electron）
• 版本：0.2.0-rc.2（exe FileVersion 与 resources/app.asar 内 package.json 均为该版本）
• Electron：44.0.0（resources/version）
• 构建提交：04f392c9ddd144fa426da2045178797da6db6c11（dshBuildCommit，dirty=false）
• 平台：Windows x64
• 安装路径：D:\Program Files\DeepseekHarness\

问题

在 Windows 桌面版中按 Ctrl + =（即 Ctrl + + 所在的物理键）和 Ctrl + - 没有任何反应，界面不会缩放；Ctrl + 0 同样无效。

期望

• Ctrl + = 放大页面
• Ctrl + - 缩小页面
• Ctrl + 0 恢复 100%
• 上限/下限与 Chromium 一致（50% ~ 500%），并且缩放级别能在会话之间保持

原因分析

缩放快捷键不是渲染进程的能力，而是挂在 Electron 应用菜单上的加速键。Electron 内置的默认菜单里有：

Zoom In    → CommandOrControl+Plus
Zoom Out   → CommandOrControl+-

但桌面壳在 Windows 上把应用菜单替换成了两个不可见的 DevTools 项：

resources/app.asar → lib/main.js（约 11921–11936 行）

const devToolsItems = [
  { role: "toggleDevTools", visible: false },
  { role: "toggleDevTools", visible: false, accelerator: "F12" },
];
const refreshApplicationMenu = () => {
  Menu.setApplicationMenu(Menu.buildFromTemplate(
    process.platform === "win32" ? devToolsItems : [...平台菜单...]
  ));
};

Windows 分支里没有 viewMenu，也没有 zoomIn / zoomOut / resetZoom，所以这三个键无人响应。
对比 macOS 分支包含 { role: "windowMenu" }，缩放在 macOS 上是存在的——属于平台行为不一致。

另外，桌面的自研快捷键层（before-input-event → setIgnoreMenuShortcuts → 转发给前端）只负责把按键转发给 Web 端做绑定，本身没有缩放实现，所以也不存在"被前端拦截"的情况。

建议修复

最小改动：把缩放项加进 devToolsItems，两个平台一致：

const devToolsItems = [
  { role: "toggleDevTools", visible: false },
  { role: "toggleDevTools", visible: false, accelerator: "F12" },
  { role: "zoomIn" },
  { role: "zoomOut" },
  { role: "resetZoom" },
];

如果希望同时提供菜单入口（右键或标题栏），也可以直接给 Windows 挂 { role: "viewMenu" }。

考虑到本应用有自定义标题栏（titleBarStyle: "hidden" + titleBarOverlay），不需要显示菜单栏；仅注册加速键即可，或让缩放项 visible: false，与其他项保持一致。

补充

• macOS 不受影响。
• 若短期内不打算做，也希望能明确说明"Windows 桌面版暂不支持页面缩放"，便于在文档中标注。

[Jarvis-Baba]

同机独立验证 + 一个补充点：没有可绕过的用户侧配置面

我在这台 Windows 机器上独立复核了本串的根因，结论一致；同时补一个本串还没有人提到的点（不存在任何配置层绕过），以及一组实测数字。

环境（与本串原作者的报告逐项吻合）

• App：DeepSeek Harness 桌面版（Electron），Windows x64
• 版本：0.2.0-rc.2（DeepSeek Harness.exe FileVersion 读数为 0.2.0-rc.2）
• 构建提交：04f392c9ddd144fa426da2045178797da6db6c11（dshBuildCommit，dshBuildDirty: false）
• 与首帖给出的版本、构建提交完全一致，因此下面是同一份产物上的读数
• 系统显示缩放：单显示器，Windows 缩放 100%（Win8DpiScaling = 0）

最后一行是有意列出的：这台机器没有开系统缩放，所以现象不是 DPI 设置造成的，而是应用内固定排版 token 造成的。

根因（我在本机 resources/app.asar 上独立复现了同一段代码）

refreshApplicationMenu 的 Windows 分支只装了两个隐藏的 DevTools 项，既没有 viewMenu，也没有 zoomIn / zoomOut / resetZoom：

const devToolsItems = [{ role: toggleDevTools, visible: false },
                       { role: toggleDevTools, visible: false, accelerator: F12 }];
Menu.setApplicationMenu(Menu.buildFromTemplate(
  process.platform === win32 ? devToolsItems : [{ label: ..., submenu: [...applicationItems(), ...devToolsItems] }, ...platformMenus()]));

即：非 Windows 分支会挂上平台菜单，Windows 分支不会。与首帖的定位一致，Ctrl + = / Ctrl + - / Ctrl + 0 在 Windows 上是没有人绑定，不是绑定坏了。

现象已实测确认

在本机 0.2.0-rc.2 上按 Ctrl + =、Ctrl + - 均无任何反应，与代码读数一致。

本串的补充点：字号设置的天花板决定它永远够不到界面文字

ui-theme 的「字号大小」范围在 0.2.0-rc.2 已放宽到 10..22 px（默认 14），但它只写一个 body 变量：

const CONTENT_FONT_SIZE_VARIABLE = --dsh-content-font-size;
body.style.setProperty(CONTENT_FONT_SIZE_VARIABLE, `${snapshot.fontSize}px`);

而界面文字走的是不参与缩放的常量 token（本机产物实测）：

Token	字号 / 行高
--dsw-font-xxxs-11	11px / 14px
--dsw-font-xxs-12	12px / 18px
--dsw-font-xs-13	13px / 20px
--dsw-font-s-14	14px / 22px
--dsw-font-markdown-code-block	11px / 19px

因此即便把字号拉满到上限 22px，侧栏 / 按钮 / 菜单 / 工具条的 11–14px 也一位不动。 这不是「数值还不够大」，而是这条设置的作用域根本不在那一层——把它继续放宽也无法解决本诉求。这个数字关系建议在评估时一并考虑：22px 已经超过界面文字的 1.5 倍，却仍然只作用于会话内容。

补充点：没有任何用户侧配置可以绕过

这点对判断严重程度有影响，且我在本机逐项确认过：

1. 客户端 ui-theme 的配置 schema 是闭集，只有两个键：

const Config = z.object({
  preference: z.union([...THEME_PREFERENCES]).default(DEFAULT_PREFERENCE).volatile(),
  fontSize: z.number().step(1).min(10).max(22).default(14).volatile()
});

因此 host 侧配置（<profile>/cordis.patch.yml 的 ui-theme 行）除了选主题和改内容字号之外，没有第三条路。

2. 产物中不存在用户样式表机制：检索 custom.css / user.css / customCss 均无命中，没有可注入自定义 CSS 的入口。
3. ThemeRuntime.register() / overrideTokens() 确实能覆盖 token 名，但那是需要写客户端插件并随包发布的通道；配置层无法注册主题，普通用户在设置里也碰不到。
4. 桌面外壳侧同样没有缩放实现：产物中检索 zoomFactor / setZoomLevel / setVisualZoomLevelLimits 均无外壳实现。

结论：在本机当前版本上，用户侧唯一的全局放大手段是改 Windows 显示缩放（设置 → 系统 → 显示 → 缩放），而那会影响整个系统、并非应用内能力。 也就是说本诉求目前连一个临时 workaround 都没有——这一点让修复的优先级更值得往上提。

对首帖建议修复的意见

首帖给的 devToolsItems 补三个 role 的最小改动看起来是对的，且不需要显示菜单栏（本应用是 titleBarStyle: hidden 的自定义标题栏），我支持这个方向。唯一想请维护者确认的是缩放是否需要跨会话持久化：Chromium 的 role 加速键改的是当前视图的 zoom level，若要「重启后保持」，可能还需要把缩放级别落盘（#7769 里也有同样的诉求）。若短期内不做，我也同意首帖的请求：至少在文档或设置里明确写出「Windows 桌面版暂不支持页面缩放」。

顺带一提，我是从本机设置里的「字号大小」已经调到 21 仍觉得整页偏小、又实测 Ctrl + = 无反应之后找到本串的。搜索路径上，#8179（字体族）与 #7769（整界面缩放）和本串是同一类缺口的不同面，建议合并考虑。