[Bug] 大会话下拖动滚动条 / 分栏手柄，浏览器主进程单线程 100% 自旋，页面长时间失去响应

[gif156359098]

Summary

当一个大会话（50 轮以上）正处于工作中（agent 在跑、最好同时有子代理在工作）、且它是当前选中的会话时，以下两种鼠标拖拽操作会让浏览器主进程（browser process）单线程 100% 自旋（该线程 Running、优先级 AboveNormal，其余线程全部 Wait），页面随即完全失去响应，持续数十秒到数分钟，直到拖拽停止才自行恢复：

• 拖动顶部栏「子代理」hover 浮窗中，子代理列表的滚动条
• 拖动对话区分栏的尺寸手柄，来回改变对话区宽度

同一页面在三个不同的 Chromium 宿主上均可复现；DSH 服务端进程全程正常（其它客户端可继续交互），只有当前这个浏览器页面卡死。

Reproduction

前置条件（关键）：

1. 一个**轮数较多（50 轮以上）**的会话
2. 该会话处于工作中 —— agent 正在执行，最好同时有子代理在工作
3. 该会话是当前选中的会话（在界面上打开并聚焦着它）

触发步骤（两种都稳定复现）：

• 方式 A（子代理浮窗）：把鼠标移到顶部栏的「子代理」上，等 hover 浮窗展开，然后按住浮窗中「子代理列表」的滚动条上下拖动
• 方式 B（分栏手柄）：按住对话区分栏的尺寸手柄，来回拖动改变对话区宽度

触发稳定性说明：

• 上述两种拖拽操作稳定复现；鼠标滚轮只是偶发，不是稳定触发方式
• 会话空闲时不容易触发，必须处于工作状态（有持续流式更新/子代理状态推送）
• 会话轮数少时未复现，50 轮以上明显更容易触发
• 与第三方插件无关（见 Environment，已在纯净 profile 下复现）

Current behavior

页面失去响应时，浏览器主进程的线程级读数：

宿主	版本	主进程 CPU	线程读数	句柄
Chrome	153.0.8010.52	94.9%	tid=9012 94.9% Running AboveNormal，其余 58/59 全 0%	不动
Edge	153.0.4234.32	96.1%	tid=25088 94.1% Running AboveNormal，其余 73/74 全 0%	1865→1865
WebView2	153.0.4234.32	97.7%	tid=17400 97.7% Running AboveNormal，其余 60/61 全 0%	不动

共同特征：单线程吃满一个核、优先级 AboveNormal、其余线程全部 Wait、句柄数不增长。renderer 进程只是正常重渲染（实测 27%~77%），不是它卡住；DSH 的 node 服务进程 CPU 平稳。

页面无响应期间，同一 DSH 服务下的其它浏览器客户端完全正常；拖拽负载停止后自行恢复。

Expected behavior

拖动子代理浮窗的列表滚动条、拖动分栏尺寸手柄，应当只引起页面按帧重绘，不应使浏览器主进程进入持续忙循环，更不应导致页面长时间（数十秒~数分钟）无法交互。

Environment

• DSH：0.1.6-alpha.2（@deepseek-ai/dsh，pnpm 全局安装）
• profile 内仅 4 个官方组合包（dsh-base / dsh-web-app / dsh-experimental-agent-team-profile / dsh-experimental-agent-team-web-profile），第三方插件已全部移除 —— 已排除第三方插件因素
• OS：Windows（x64）
• 浏览器：Chrome 153.0.8010.52、Edge 153.0.4234.32、WebView2 Runtime 153.0.4234.32（三种宿主均复现，与具体浏览器产品无关，指向 Chromium 层）
• 会话状态：running（agent 执行中，含活跃子代理），轮数 50+，且为当前选中会话

补充分析（供参考，不影响复现）

1. 为什么必须「会话工作中」才触发

会话工作时，页面处于持续流式更新状态：消息增量、子代理状态、列表投影都在不停重建。此时拖拽产生的 100+ Hz pointermove 与这些更新叠加，才会把主进程推入忙循环；会话空闲时同样拖拽，负载不足以触发。子代理在跑会进一步放大——浮窗里的子代理列表需要反复重建（对应 trace 中的 indexSubagentDescendants）。

2. 前端拖拽 helper 没有做按帧节流

@deepseek-ai/dsh-web-frontend@0.1.6-alpha.2 的 dist/assets/index-8VXBH-f-.js，偏移 593246 处的拖拽 helper（压缩名 Tw）：

function Nw(e, r) { typeof e.setPointerCapture == "function" && e.setPointerCapture(r) }

function Tw(e, r, i) {
  Nw(e, r);
  const s = new AbortController, { signal: l } = s, c = f => f.pointerId === r;
  return window.addEventListener("pointermove", f => {
    c(f) && i.move(f)            // 每个 pointermove 直接同步调用 move
  }, { signal: l }),
  window.addEventListener("pointerup", f => { c(f) && (s.abort(), i.up(f)) }, { signal: l }),
  window.addEventListener("pointercancel", f => { c(f) && (s.abort(), i.cancel()) }, { signal: l }),
  () => { s.abort() }
}

要点：每个 pointermove 都直接、同步执行 i.move(f)，没有任何 requestAnimationFrame 或时间戳节流；监听还挂在 window 上。整个 index bundle 中 requestAnimationFrame 仅出现 2 次，而 ResizeObserver 出现 12 次，节流基本没用在拖拽路径上。

3. 自采 Chrome trace 的热点与操作吻合

用户自采 trace（432.9s、800,691 个事件、233,167 个 CPU 样本 / 85.8s）：

idle                                      75.4%
(program)  布局/样式/绘制/合成/GC 合计     11.4s
JS                                          约 8%

热点函数：
  toBottom                   672ms   ← 滚动到底
  buildListSnapshot          296ms   ← 列表快照重建（@deepseek-ai/dsh-api-session-controller/lib/client.js，带 listSnapshotCache）
  projectList                 79ms
  indexSubagentDescendants    58ms   ← 子代理后代索引（对应子代理浮窗）

4. 可能的机制

拖拽产生 100+ Hz pointermove → 每个事件同步执行重量级重算 → 与流式更新叠加 → renderer 侧输入处理滞后 → Chromium browser 进程的输入事件路由积压 → 主进程进入忙循环（单线程 Running/AboveNormal）。这也解释了滚轮（离散事件、浏览器自带节流）为何不稳定触发、会话越大越容易触发（列表快照与子代理索引耗时随规模增长）、以及为何必须会话处于工作中。

5. 建议

在拖拽 helper 中按帧合并 pointermove（每帧最多执行一次 move），手感不变但负载可降一个数量级：

function Tw(e, r, i) {
  Nw(e, r);
  const s = new AbortController, { signal: l } = s, c = f => f.pointerId === r;
  let pending = 0, last = null;
  const onMove = f => {
    if (!c(f)) return;
    last = f;
    if (pending) return;
    pending = requestAnimationFrame(() => { pending = 0; i.move(last); });
  };
  window.addEventListener("pointermove", onMove, { signal: l });
  // pointerup / pointercancel 同原实现，注意同时 cancelAnimationFrame(pending)
}

6. 附：这不是第三方插件导致

最初怀疑是第三方插件，已通过实验排除：移除全部第三方插件（profile 只剩 4 个官方组合包）后，Chrome 上仍稳定复现；且该现象在三种不同 Chromium 宿主上表现完全一致。