Windows: 窗口拖不动 —— 拖拽区声明写在伪元素上，Chromium 不认

[lgc2374015]

环境

• Windows 10 专业版 22H2 (19045)
• DSH Desktop 0.2.2-rc.1
• Electron 44.7.0 / Chromium 152
• 复现概率：100%（每次启动都复现）

现象

DSH 主窗口无法用鼠标拖动。右上角的最小化 / 最大化 / 关闭可以正常点击（它们是系统原生覆盖层），页面内一切交互正常，只有拖动标题区无效。

复现步骤

1. 启动 DSH Desktop，打开任意会话；
2. 在标题区（「应用 / 编辑」那一行，或它右侧的空白处）按住左键拖动；
3. 窗口不动。

根因

窗口是 titleBarStyle: "hidden" + titleBarOverlay 的无边框窗口，拖动依赖页面里的可拖区域。当前实现把它声明在一个伪元素上：

[data-windows-titlebar] .mP3x-q_frame::before {
  content: "";
  height: var(--dsh-windows-titlebar-height);   /* 实测 40px，正常 */
  -webkit-app-region: drag;
  position: absolute;
  inset: 0 0 auto;
}

Chromium 计算 draggable region 时只扫描真实元素，::before 上的 -webkit-app-region 不会被收集。所以这条带子高度、位置、属性全部正确，却永远不生效。

实测证据

通过 CDP（--remote-debugging-port）读取运行时状态：

• <html data-windows-titlebar> 存在；--dsh-windows-titlebar-height = 40px；
• getComputedStyle(frame, '::before') → content: ""、height: 40px、-webkit-app-region: drag、position: absolute、top: 0px；
• 对窗口发送 WM_NCHITTEST，标题区各点全部返回 HTCLIENT（不是 HTCAPTION）；
• 用真实鼠标消息在 (x, top+18) 按下并拖动：窗口位移 0 px；
• 对照实验：把同样的 html, body { -webkit-app-region: drag } 注入页面后，同样的拖动 → 窗口位移 70 px；把 -webkit-app-region: drag 加在一个真实 div（position: fixed; top: 0; height: 40px）上，同样生效。
• 另：在 Page.reload 之后动态插入真实元素可生效；冷启动时若元素在很早的阶段插入，则 Chromium 不再重算，需移除后重新插入才生效——说明区域集合只在特定时机刷新。

建议修法

1. 把可拖区域从 ::before 换成真实元素（一个 position: fixed; top: 0; height: 40px; -webkit-app-region: drag 的空 div），或
2. 在页面里对某个已存在的真实元素声明 -webkit-app-region: drag 并用后代 no-drag 收窄范围；注意左侧菜单与右侧原生按钮区必须保持 no-drag。

临时绕过（用户侧）

在页面中插入一条真实元素即可：

const el = document.createElement('div')
el.style.cssText = 'position:fixed;top:0;left:200px;right:150px;height:40px;z-index:2147483000;-webkit-app-region:drag'
document.body.appendChild(el)

冷启动时需要「挂载 → 移除 → 再挂载」一次才会被收集。

[PerryLink]

你说得对，那条 drag 声明在伪元素上，Chromium 收不到——这不是"高度或位置没对上"，是选择器本身失效。

源码位置

packages/client/ui-layout/src/client/AppFrame.module.css:40-47（master fcc0ad46）：

:global([data-windows-titlebar]) .frame::before {
  content: '';
  position: absolute;
  inset: 0 0 auto;
  height: var(--dsh-windows-titlebar-height);
  background: var(--dsw-specific-sidebar-fill);
  -webkit-app-region: drag;
}

整条带子的高度、定位、app-region 都写对了，但挂在 ::before 上。Electron 收集 draggable region 时取的是布局对象的 -webkit-app-region，伪元素生成的是匿名盒子，不在它扫描的元素集合里——所以你 CDP 里能看到 getComputedStyle(frame, '::before') 值全对，窗口却拖不动。

修法形状

把 drag 挪到真实元素上，二选一：

1. 直接给 .frame 加 -webkit-app-region: drag，再把里面可交互的容器（标题行、按钮）标回 no-drag——base.css 里 html[data-platform='darwin'] [data-window-drag] 那套就是这个思路，Windows 可以直接借用；
2. 或者保留这条伪元素只做背景，另外插一个真实的高度为 var(--dsh-windows-titlebar-height) 的 div 专管拖拽。

要注意 .frame::before 现在还兼着"给标题带铺底色"的职责，改的时候别把背景一起删了。

顺带：这个 bug 和 macOS 那条"窗口拖不动"（#12261）可能同源——如果两边都依赖伪元素/错误元素上的 app-region，一次修两处。

只读了 master fcc0ad46 的源码；你的 CDP 读数我没法复算。

[lgc2374015]

补三样你手上没有的运行侧证据，帮修的时候少踩坑： 1. 可复算的验法：带 --remote-debugging-port 启动，CDP 里 getComputedStyle(document.querySelector('[class*="frame"]'), '::before') 能看到 app-region:drag / height:40px；对窗口发 WM_NCHITTEST，标题区各点全返回 HTCLIENT（不是 HTCAPTION）；再用真实鼠标消息在 (x, top+18) 按下拖动，窗口位移 0px。把同样的声明放到一个真实 div 上，同样输入位移 70px。 2. 真实元素那套在实机上是可行的：我按你的方案 2 做了个等价的最小实现（position:fixed; top:0; height:var(--dsh-windows-titlebar-height); -webkit-app-region:drag，左边让 200px 给「应用/编辑」菜单、右边让 150px 给原生按钮），装上就能拖，内容区不会误拖（实测 0px）。 3. 一个实现坑，改的人要知道：冷启动时若这个真实元素在页面很早就插入，Chromium 已经算完可拖区域、不会重算 —— 元素在、属性对、依旧拖不动。要在页面就绪后「移除再插入」一次（我是在 1.5/4/8/15 秒各 remount 一次兜底），热重载（Page.reload）时反而一次就生效，所以只看 reload 会验漏。 另外确认一下你说的第 2 条：.frame::before 还兼着给标题带铺底色，别一起删。 刘桂成 ***@***.***

[PerryLink]

你补的这三样正是缺的，尤其第 3 点——冷启动那次不重算，树里其实有个专门的机制，只是没覆盖 Windows。

现成的东西

packages/client/web/src/window-drag/recall.ts 就是干这个的：它盯住带 data-window-drag 的行，按帧量 box，几何一变就给 body 打一帧 data-window-drag-recall，CSS 那边（packages/client/web/src/base.css:59-69）用这个标记强制 Electron 重收一次 region（注释里直接写了 electron#32341）。所以"元素在、属性对、但 Chromium 不重算"这件事，作者是知道的，并且已经写了解法。

但它是 darwin 专用的

recall.ts:63：

if (doc.documentElement.dataset.platform !== 'darwin') return () => {}

Windows 上这个 watcher 压根不装，所以你只能用定时 remount 兜底——那不是你的实现问题，是这套机制还没铺到 Windows。

所以修法建议改成

把 [data-windows-titlebar] 那条带子也标成 data-window-drag（或给它一个同义的 mark），然后把这个 watcher 的平台门去掉、让它对 Windows 也生效。这样"插入时机"就不再需要靠 1.5/4/8/15 秒的 remount 去撞——几何一变，recall 脉冲自动来一次。

你的最小实现（左边让 200px、右边让 150px，内容区 0px 误拖）可以直接当那条真实元素的写法参考。

只读了 master fcc0ad46 的源码；你的 CDP/WM_NCHITTEST 数据我没法复算。

[zzzz1357902468]

补一组对照实验，结果和标题里的根因判断不一致，供参考。

环境：DSH Desktop 0.2.2-rc.1 · Electron 44.7.0 · Node 24.21.0 · win32 x64 · Windows 11 25H2（10.0.26200.7705）· 缩放 175% · 双显示器。复现率 100%（每次启动）。

现象判据：按住标题带（「应用/编辑」右侧空白处）时，渲染进程收到的是普通 pointerdown。若系统在该点返回 HTCAPTION，事件根本不会进渲染进程。所以问题不是「拖动被应用拦下」，而是该窗口没有任何生效的可拖拽区域。

对照实验：用 Electron 43.3.0 起一个同款窗口（titleBarStyle: 'hidden' + titleBarOverlay），页面里同时放「真实元素 app-region: drag」与「::before 伪元素 app-region: drag」，再从进程外用 WM_NCHITTEST 读系统判定：

采样点	系统判定
真实元素 app-region: drag	HTCAPTION
::before 伪元素 app-region: drag	HTCAPTION
两者之上再覆盖一层无 app-region 的元素	仍 HTCAPTION
追加 backgroundMaterial: 'mica' + 透明背景 + roundedCorners + thickFrame	仍 HTCAPTION
空白客户区	HTCLIENT
原生标题栏按钮区	HTMAXBUTTON

窗口样式位 0x14C70000，与应用窗口实测值一致。

结论：伪元素不是原因（伪元素的 app-region 在 43.3.0 上能正常变成 HTCAPTION）；Mica / 透明背景 / 圆角 / thickFrame 也不是；被后来的元素覆盖也不会丢。也就是说 CSS 写法本身没有问题，剩下的差异集中在 Electron 44.7.0 与该窗口组合（或主进程窗口代码）——建议在 44.7.0 上复测 -webkit-app-region 是否仍向 browser 进程上报 draggable regions。

旁证：0.2.1-rc.5 正常（原生标题栏），0.2.2-rc.1 起失效；macOS 侧 #12261 也是 0.2.2-rc.1 才回归。

如果需要，我可以把那个最小 Electron 探针（main.cjs + index.html + WM_NCHITTEST 采样脚本）整理成一个仓库或补到帖子里。