[Bug][Desktop][macOS] 窗口完全无法拖动：连标记了 data-window-drag 的 chrome 行也拖不动（0.2.0-rc.2 / Electron 44）

[adamcjm]

[Bug][Desktop][macOS] 窗口完全无法拖动：连标记了 data-window-drag 的 chrome 行也拖不动

环境

项	值
DSH Desktop	0.2.0-rc.2（CFBundleVersion 0.2.0-rc.2）
Electron	44.0.0
系统	macOS 27.0.1 (26A434)，Apple Silicon
窗口	1280×820，非全屏、非最大化，侧边栏展开

现象

窗口无法用鼠标拖到任何位置：在窗口内按下并拖动，窗口几乎不动（极限情况下只位移 1px），既不能换位置也不能拖到另一块屏幕。

本条与 #7937 的第 3 条同源，但实测比那条更严重。#7937 的描述是「只有少数几行 chrome 标了拖拽（侧栏 topStrip / logoRow、会话 header 等），最顶部约 48px 那条空白带没标，所以用户凭直觉拖那里拖不动」；在本机 0.2.0-rc.2 上，连这些已经标记了 data-window-drag 的行也拖不动。

实测（同一台机器、同一注入方式，起点为窗口内 CSS px）

起点	位置	结果
(150, 44)	侧边栏 topStrip 空白段（data-window-drag 行内）	拖动 (100, 100) 后窗口位移 1px，等于没动
(106, 71)	侧边栏 logoRow（data-window-drag 行内）	无位移
(106, 21)	侧边栏 topStrip 内	无位移
(747, 23)	会话 header / 标签栏行	无位移
(640, 4)	窗口最顶端	无位移
同上任一点双击	期望触发系统「双击标题栏」动作	无任何反应

对照与排除项：

• 用完全相同的注入方式去拖 ChatGPT（同为 Electron）窗口的标题栏：一次就成功 —— 系统和注入方式正常。
• 用 BrowserWindow.setBounds 程序化移动同一窗口：成功 —— 窗口没有被禁止移动（不是 movable: false）。
• 应用内其他鼠标交互（点击、滚动、拖拽分隔条）正常 —— 不是窗口整体收不到鼠标事件。

代码定位

1. macOS 窗口本来就没有原生标题栏：apps/desktop/src/main.ts 在 darwin 分支用
   titleBarStyle: 'hiddenInset' + trafficLightPosition + vibrancy: 'sidebar'。
   于是窗口拖动只能来自页面里的 -webkit-app-region 盒子。

2. 全树唯一的 darwin drag 规则在 packages/client/web/src/base.css：

   html[data-platform='darwin'] [data-window-drag] { -webkit-app-region: drag; }

   [data-window-drag] 只出现在 ui-theme 门禁清单 CHROME_ROWS 列出的那几行：ui-sidebar 的 topStrip / logoRow、ui-conversation 的 header、ui-dockkit 的 tabStrip、插件页的 pageHead / detailTop、PlatformOverlay 的 header、OnboardingSurface 的 dragBand。

3. no-drag 侧有三处：body 上的 data-window-drag-recall、body > :not(#root)、以及 interactive 选择器 :is(button, a, …, [tabindex], [role=…])。

4. packages/client/web/src/window-drag/recall.ts 在 chrome 行几何变化时把 data-window-drag-recall 设到 body 上（设计意图是借一次 computed app-region 值变化让 Electron 重新收集拖拽矩形，electron#32341）。

合成规则核对（三条都指向「设计本身是自洽的」）

• Chromium ui/gfx/draggable_region.h：drag 矩形相加、no-drag 矩形相减，按列表顺序、后面的胜出 —— 与 packages/client/web/src/window-drag/regions.ts 里写的模型一致，所以 body 上的 recall 盒子（DOM 顺序早于 #root 内的行标记）理论上不会抹掉行标记。
• Electron 23 的 breaking change（docs: document change in draggable region behavior on macOS electron/electron#37408）：macOS 上 drag 盖住 no-drag 的行为开始生效。
• Electron shell/browser/api/electron_api_web_contents.cc：无条件调用 SetSupportsDraggableRegions(true)（Draggable regions in subframes/child windows not respected electron/electron#49256），所以不是「这种窗口类型没启用拖拽区收集」。

也就是说：按代码和合成规则推演，这些行应该是可拖的；但实测不可拖。 这一点是本帖要报的核心。

建议的下一步

1. 用官方调试开关启动桌面端，看 Electron 实际认到哪些拖拽区域：

   ELECTRON_DEBUG_DRAGGABLE_REGIONS=1 "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness"

   画出来为空 → 问题在「页面 → 原生」的收集环节；画出来了但拖动仍无效 → 问题在窗口层（hiddenInset + vibrancy 的组合）。

2. 在窗口 DevTools（webPreferences.devTools: true，但本机 ⌘⌥I 未打开，可能被快捷键系统截获）里跑：

   document.documentElement.dataset.platform               // 期望 'darwin'
   document.body.hasAttribute('data-window-drag-recall')   // 稳态期望 false
   [...document.querySelectorAll('[data-window-drag]')]
     .map(el => [el.className, el.getBoundingClientRect().toJSON()])
   [...document.body.children].filter(el => el.id !== 'root')
     .map(el => [el.tagName, el.getBoundingClientRect().toJSON()])

   最后一条用来排除「有常驻的、覆盖全窗口的 body 直接子元素把整个拖拽面减掉」（body > :not(#root) 规则会把它变成 no-drag）。

临时规避

在拖拽恢复之前，可以在 DevTools Console 里插一条临时拖拽带：

const bar = document.createElement('div')
bar.style.cssText = 'position:fixed;top:0;left:0;right:0;height:10px;z-index:2147483647;-webkit-app-region:drag'
document.body.appendChild(bar)

内联 app-region 优先于 ui-web 的 body > :not(#root) 规则；刷新或重启后失效。

[adamcjm]

进展：应用内实测把根因从「窗口层」改判为「页面层」

在原帖基础上补一组从真实窗口内部读到的证据。结论要修正我自己原帖里的首要怀疑方向：原生窗口完全正常，问题出在页面的 no-drag 覆盖。

实测数据

DSH Desktop 0.2.0-rc.2 · Electron 44.0.0 · macOS 27.0.1 (26A434)，1280×820 窗口、侧边栏展开：

platform: darwin
computed app-region · body: none
computed app-region · 首个 [data-window-drag] 行: drag     ← 属性支持与级联都正常
recall 标记当前: 未设置                                     ← 不是 recall 常驻
recall 脉冲次数（本次加载以来）: 3
app-region 盒子: 4296 个（drag 37 / no-drag 4259）

drag 行 (4):
  topStrip    280x52  @0,0    app-region=drag
  logoRow     256x60  @12,40  app-region=drag
  header     1000x76  @281,0  app-region=drag
  tabStrip    576x38  @1280,0 app-region=drag

drag 行存在，但它的像素被挖掉了

按项目自己的合成模型（packages/client/web/src/window-drag/regions.ts：「文档顺序里最后一个包含该点的盒子决定」）采样：

采样点	位置	判定
侧边栏 topStrip 空白	(150, 44)	不可拖
侧边栏 logoRow	(106, 71)	不可拖
窗口最顶端	(640, 4)	可拖

topStrip 的矩形是 0,0 280x52、logoRow 是 12,40 256x60，两个采样点都在其内部，却判为不可拖 —— 说明这些矩形被文档顺序更靠后的 no-drag 盒子减去了。4296 个 app-region 盒子里有 4259 个 no-drag，正是 ui-web/base.css 那条 interactive 选择器在真实 DOM 上的命中量：

html[data-platform='darwin'] :is(
  button, a, input, select, textarea, summary, [contenteditable='true'], [tabindex],
  [role='dialog'], … , [role='textbox']
) { -webkit-app-region: no-drag; }

决定性对照：原生窗口层是好的

往 document.body 追加一个 10px 高、position:fixed;top:0、内联 -webkit-app-region: drag 的条之后，窗口立刻可以被拖动——页面内 window.screenX/screenY 记录到两次真实位移（215,82 → 171,149，171,149 → 181,118）。

结论修正

• hiddenInset + vibrancy 下 Electron 忽略了拖拽区 → 不成立：内联 drag 盒子能拖，原生层工作正常。
• data-window-drag-recall 常驻把整个拖拽面减掉 → 不成立：实测稳定态为「未设置」，脉冲也只有 3 次。
• 成立：chrome 行虽然正确声明了 drag，但其中绝大部分像素被「文档顺序更晚、与之重叠的 no-drag 盒子」减去，实际可拖区域几乎只剩最顶端的几个像素（y=4 可拖、y=20 起不可拖）。这同时解释了 [Desktop][macOS] 请补齐桌面端的基础交互：⌘+/-/0 缩放、⌘F 页面内搜索、窗口顶部拖动 #7937 第 3 条的直观感受——「最像标题栏的那条带拖不动」。

建议

1. 用 ELECTRON_DEBUG_DRAGGABLE_REGIONS=1 启动即可直接看到挖空后的真实拖拽面（预期：只剩下顶部极窄的一条）。
2. 修复方向在页面层，不在窗口层。 例如任选其一：
   • 收窄那条 interactive no-drag 选择器——例如把只用于程序化聚焦的 [tabindex='-1'] 排除在外，它本来是容器级的焦点目标，却因此把整个 chrome 行挖空；
   • 或调整 DOM 顺序，让 chrome 行的 drag 声明排在覆盖它的容器之后；
   • 或按 [Desktop][macOS] 请补齐桌面端的基础交互：⌘+/-/0 缩放、⌘F 页面内搜索、窗口顶部拖动 #7937 的诉求补一条真正覆盖窗口顶部的 drag band。
3. 在修复落地前，用户侧可用的临时办法就是那条内联 drag band（本贴实测有效）。

数据由一个临时客户端插件在窗口内采集（只读 DOM 与 screenX/screenY，不改动任何官方文件）。需要的话我可以把插件与采集逻辑整理出来。