[Bug][macOS][v0.1.0-rc.6] “添加工作区”缺少即时反馈，目录选择器启动延迟且可能未置前

[Carleo10032]

问题摘要

在 macOS 上点击侧栏“添加工作区”按钮后，界面没有即时反馈。系统目录选择器出现前存在明显可感知的等待，容易让用户误以为点击没有生效并再次点击。

该现象已在以下两种环境中复现：

• 普通桌面浏览器打开 DSH Web UI；
• 基于 WKWebView 的 macOS 桌面包装应用。

两种环境的表现一致，因此问题位于 DSH Web UI 与 host native directory picker 的公共调用链路，并非 WKWebView 包装器特有问题。

本报告只讨论侧栏标题栏中的“添加工作区”按钮，不讨论 Hero 页面中的工作区选择菜单。

环境

• DeepSeek Harness：0.1.0-rc.6
• 操作系统：macOS
• 服务地址：127.0.0.1:3080
• 目录选择能力：native directory picker
• 当前 macOS native picker 实现：osascript + AppleScript choose folder
• 已复现客户端：
  • 普通桌面浏览器
  • DeepSeekHarnessMac（WKWebView）

已确认现象

1. 点击侧栏“添加工作区”按钮后，按钮本身没有 loading、pressed 或 disabled 状态。
2. 从点击到系统目录选择器出现之间存在明显可感知延迟。
3. 等待期间按钮仍然可以再次点击，没有防重复触发机制。
4. 在普通浏览器和 WKWebView 包装应用中，目录选择器都可能没有立即出现在最前方。
5. 宽侧栏模式下按钮命中区域约为 28 × 28px，点击边缘时体验不够稳定。

复现步骤

1. 在 macOS 上运行：

   npx @deepseek-ai/dsh web

2. 使用普通桌面浏览器打开：

   http://127.0.0.1:3080
   

3. 确保左侧栏处于展开状态。

4. 点击“工作区”标题右侧的“添加工作区”按钮。

5. 观察系统目录选择器出现前的按钮状态。

6. 在选择器出现前尝试快速再次点击按钮。

7. 取消目录选择器，观察按钮和选择流程是否正确复位。

8. 在 WKWebView 包装应用中重复上述操作，可以观察到相同的延迟和反馈缺失。

当前行为

• 点击后按钮外观没有变化。
• 用户无法判断点击是否已被接受。
• 等待过程中按钮仍可重复点击。
• 系统目录选择器出现存在可感知延迟。
• 目录选择器可能没有立即成为最前方窗口。
• 较小的按钮命中区域进一步放大了“不跟手”的感受。

期望行为

• 点击后按钮立即显示 busy/loading 状态。
• busy 期间按钮不可重复点击。
• 目录选择器取消、报错或工作区创建完成后，busy 状态统一清理。
• 系统目录选择器应可靠地出现在最前方。
• 按钮应具有更舒适、稳定的点击区域。

源码观察

1. 按钮使用 toggle 状态

侧栏按钮当前执行：

setWsPickerOpen(v => !v)

相关文件：

packages/client/ui-workspace/src/client/WorkspaceBrowser.tsx

对于侧栏“只添加工作区”的入口，toggle 并不是必需的。使用幂等的 setWsPickerOpen(true) 更符合该操作的语义，也可以避免重复点击反转外层状态。

2. 目录流程在后续 Effect 中启动

WorkspacePickFlow 在 addOnly=true 时，通过 Effect 检测：

open && addIsTheOnlyEntry && !flowBusy

条件满足后才调用 openDirectoryFlow()。

相关文件：

packages/client/ui-workspace/src/client/WorkspacePicker.tsx

这一轮 React 状态往返本身不是系统选择器延迟的主要来源，但按钮没有即时反馈，所以等待过程会被用户感知为“点击没有生效”。

3. 已有 flowBusy 没有反馈给侧栏按钮

WorkspacePickFlow 已经计算：

const flowBusy = flowOpen || pickingFolder

这个状态能够覆盖：

• 正在打开或等待目录选择器；
• 用户已经选择目录，正在执行 createWorkspace；
• 用户取消选择器；
• 目录选择器报错；
• 工作区创建成功或失败。

但目前该 busy 状态没有反馈给侧栏“添加工作区”按钮，主要只用于禁用菜单项。

4. macOS picker 每次启动 osascript

macOS 分支通过外部 osascript 进程执行 AppleScript choose folder：

packages/host/directory-picker-native/src/index.ts

外部进程启动以及 macOS 的应用激活、窗口焦点行为，会增加实际等待，并可能影响目录选择器的置前表现。

由于普通浏览器和 WKWebView 中均能复现相同行为，这一现象与 host 侧 native picker 的公共实现一致。

5. 按钮命中区域较小

宽侧栏模式下，按钮约为：

width: 28px;
height: 28px;

标题操作区域还设置了固定 max-width 和 overflow: hidden。如果扩大按钮，需要同步调整父容器宽度，否则新增的命中区域可能被裁剪。

建议的最小修复

1. 幂等打开并立即进入 busy

侧栏按钮可以改为：

onClick={() => {
  if (workspacePickerBusy) return
  setWorkspacePickerBusy(true)
  setWsPickerOpen(true)
}}
disabled={workspacePickerBusy}
aria-busy={workspacePickerBusy}

busy 时显示固定尺寸的 spinner，避免按钮内容切换造成布局跳动。

2. 将 flowBusy 变化反馈给调用方

为 WorkspacePickFlow 增加一个可选回调：

onFlowBusyChange?: (busy: boolean) => void

仅在 flowBusy 真正翻转时通知调用方。侧栏入口使用该回调维持并最终清理按钮 busy 状态；Hero 等其他入口不传该属性，继续保持现有行为。

这样可以统一覆盖：

• 取消目录选择；
• 目录选择器报错；
• createWorkspace 成功；
• createWorkspace 失败。

不需要在父组件分别维护 openingPicker 和 adoptingWorkspace。

3. 扩大命中区域

建议仅将侧栏“添加工作区”按钮扩大到约 36 × 36px，并同步调整标题操作容器宽度。

如果宽态下同时存在一个 28px 按钮、一个 36px 按钮和 4px 间距，父容器至少需要约：

28 + 4 + 36 = 68px

放大时还应检查 section header 的高度，避免按钮纵向裁剪。

4. macOS 原生选择器作为独立增强

在通用 DSH host 中，可以继续改进 osascript 的应用激活和焦点行为。

对于原生 macOS 宿主，也可以考虑允许宿主提供目录选择能力，例如：

DSH client directory picker
  → native host bridge
  → NSOpenPanel
  → selected path
  → createWorkspace

这一部分属于独立的平台增强，不需要与按钮反馈修复绑定。

影响

该问题不会造成工作区数据损坏，但会明显影响第一次使用和频繁切换项目时的体验：

• 用户难以确认点击是否成功；
• 容易产生重复点击；
• 目录选择器未置前时，看起来像功能失效；
• 较小的命中区域会进一步放大“点击没有生效”的感受。

由于普通浏览器中也能复现，该问题属于 DSH Web UI 与 host native picker 的公共链路，而不是某个桌面包装器的兼容性问题。

补充观察：尚待稳定复现

以下行为目前只作为观察记录，不作为本报告的确定结论：

1. 在目录选择器出现前快速再次点击，取消选择器后可能再次触发目录选择流程。
2. Hero 工作区菜单打开时，再次点击菜单触发按钮，可能存在 document-level pointerdown 关闭后，按钮 click 又重新打开的竞态。

这两个现象涉及不同入口，建议在获得稳定复现步骤后分别讨论。

补充复现环境

我还在一个非官方 SwiftUI macOS 包装项目中复现了相同行为：

Carleo10032/deepseek-harness-mac

该项目启动官方 dsh web 本地服务，并在 WKWebView 中加载官方 Web UI。它没有替换工作区选择流程或 host native directory picker。

由于普通浏览器中也能独立复现，因此该仓库只作为补充复现环境和 macOS 宿主参考，不是本问题成立的前提。

可补充材料

如有需要，我可以进一步提供：

• 点击到目录选择器出现的屏幕录制；
• 快速重复点击的录屏；
• 普通浏览器中的复现录屏；
• WKWebView 中的复现录屏；
• 基于上述最小修复方案的本地验证结果。