[Bug][Web client] Safari/WebKit：浮层内点击被 onBlur 吞掉（relatedTarget === null）/ clicks inside portaled panels are swallowed when relatedTarget is null

[xirener]

中文

摘要

在 Safari（任何 WebKit 浏览器）中，若干客户端插件把 onBlur 里 relatedTarget === null 误判为“焦点离开组件”，于是在 mousedown 与 mouseup 之间就卸载了浮层，选项的 click 永远不触发。用户看到的是：菜单/面板有内容、可以点，但点了没有任何效果，也不报错。Chromium 系（Chrome/Edge）不受影响。

环境

• @deepseek-ai/dsh 0.1.6-alpha.2（npm 全局安装），macOS + Safari
• 受影响包（源码位于本仓库）：
  • packages/client/ui-model-selection（@deepseek-ai/dsh-client-ui-model-selection）——模型菜单点选无效（影响最大）
  • packages/client/ui-directory-picker-browse——编辑路径时点击卡片内任意不可聚焦元素会取消编辑
  • packages/client/ui-workflow-run——运行/阶段 disclosure 的 pending 收起被误触发，面板在指针下收起
  • packages/client/ui-sidebar-documentpreview——经检查已安全，无需改动（见文末）

实测环境（报告者机器）

项目	值
DSH	@deepseek-ai/dsh 0.1.6-alpha.2（npm 全局安装）
Node	v26.7.0
操作系统	macOS 27.0（Build 26A428），arm64
设备	Mac mini · Mac16,10 · Apple M4（10 核：4P+6E）· 16 GB
浏览器	Safari 27.0（WebKit）

关于正文中的本地模型名：文中出现的 Qwen3.8-27B-AWQ-INT4 是本报告者在局域网内另一台工作站上自行部署的模型（经本机 new-api 网关转发），不是任何公开托管的模型；它只是复现时用到的路由标签，与本 bug 无关。本问题是在升级到最新版 dsh 之后、尝试改用这个本地模型时开始出现的。

复现步骤（模型菜单，稳定复现）

1. macOS Safari 打开 dsh web 页面；
2. 点击输入框右下角模型按钮，菜单打开（能看到模型列表）；
3. 点击「模型」行进入模型列表；
4. 点击任意一个与当前不同的模型；
5. 结果：菜单关闭，模型名不变，没有发出任何 session/selectModel 请求。

期望结果

选中该模型，触发标签更新，并发出 session/selectModel。

根因

WebKit 点击 <button> 不会给它焦点。当 mousedown 落在选项上时，此前被代码 .focus() 聚焦的菜单项触发 focusout，且 WebKit 给出的 event.relatedTarget 是 null。组件的 onBlur 只判断“新焦点是否仍在组件内”，null 被判成“焦点已离开”，于是立刻 close()，把 portal 菜单在 mousedown 与 mouseup 之间卸载，选项上的 click 永远不会触发。
Chromium 会在点击时聚焦按钮，relatedTarget 指向菜单内部元素，onBlur 提前 return，因此 Chrome/Edge 正常。
这也解释了为什么“刷新页面 / 重启浏览器 / 重启 dsh / 换工作区”都无效：它不是页面状态问题，而是客户端代码问题。

证据（Playwright 真实 WebKit 引擎复现）

修复前的同一次点击：

mousedown tgt=SPAN:Qwen3.8-27B-AWQ-INT4  rel=null
focusout  tgt=BUTTON.option:DeepSeek-V41-Flash  rel=null
mouseup   tgt=DIV

菜单消失、标签不变、network 里没有 session/selectModel。
修复后同一次点击：

focusout  ...  rel=null
mouseup   tgt=SPAN:Qwen3.8-27B-AWQ-INT4
click     tgt=SPAN:Qwen3.8-27B-AWQ-INT4

正常发出 session/selectModel，标签更新为所选模型。

建议修复

把 relatedTarget === null 当作“未知”而不是“离开组件”。

packages/client/ui-model-selection（ModelSelect 的 onBlur）：

const onBlur = (event) => {
  const next = event.relatedTarget;
  if (next === null) return; // WebKit：mousedown 落在不可聚焦元素（含 portal 菜单按钮）时为 null
  if (next instanceof Node && (rootRef.current?.contains(next) === true || menuRef.current?.contains(next) === true)) return;
  close();
};

packages/client/ui-workflow-run（settleRunBlur、settlePhaseBlur 两处）：

if (!(event.relatedTarget instanceof Node) || event.currentTarget.contains(event.relatedTarget)) return;

packages/client/ui-directory-picker-browse：

if (event.relatedTarget === null) return;
if (event.relatedTarget instanceof Node && card.contains(event.relatedTarget)) return;

风格参照：packages/client/ui-sidebar-documentpreview 本来就写成 if (event.relatedTarget instanceof Node && …)，null instanceof Node === false，天然不受影响——这也是我建议的统一写法。

本地验证

• Playwright WebKit：修复前稳定复现；修复后点选成功（发出 session/selectModel、标签更新）。
• 点击菜单外部仍会正常关闭（由原有 document mousedown 处理器负责），未引入回归。
• 三个 bundle node --check 通过，整页加载 0 console/page 错误。

---

English

Summary

In Safari (any WebKit browser) several client plugins treat relatedTarget === null inside onBlur as "focus left the widget". They therefore unmount a portal between mousedown and mouseup, so the option's click never fires. The user sees a populated, clickable menu that silently does nothing — with no error. Chromium-based browsers are unaffected.

Environment

• @deepseek-ai/dsh 0.1.6-alpha.2 (global npm install), macOS + Safari
• Affected packages (sources in this repository):
  • packages/client/ui-model-selection — picking a model does nothing (highest impact)
  • packages/client/ui-directory-picker-browse — clicking any non-focusable content inside the dialog card cancels the in-progress path edit
  • packages/client/ui-workflow-run — the pending closure of a run/phase disclosure fires on such clicks and collapses the panel under the pointer
  • packages/client/ui-sidebar-documentpreview — verified safe; no change needed (see below)

Tested environment (reporter machine)

Item	Value
DSH	@deepseek-ai/dsh 0.1.6-alpha.2 (global npm install)
Node	v26.7.0
OS	macOS 27.0 (build 26A428), arm64
Device	Mac mini · Mac16,10 · Apple M4 (10-core: 4P+6E) · 16 GB
Browser	Safari 27.0 (WebKit)

About the local model name in this report: Qwen3.8-27B-AWQ-INT4 is a model the reporter deploys on a separate workstation on the local network (relayed through a local new-api gateway). It is not a publicly hosted model — it is only the route label used while reproducing, and it is unrelated to the bug itself. The problem started after upgrading to the latest dsh version, while switching to that local model.

Steps to reproduce (model menu; deterministic)

1. Open the dsh web page in Safari on macOS.
2. Click the model control at the bottom-right of the composer; the menu opens and lists models.
3. Click the "Model" row to drill into the model list.
4. Click any model other than the current one.
5. Result: the menu closes, the model label does not change, and no session/selectModel request is sent.

Expected

The picked model is applied, the label updates, and session/selectModel is sent.

Root cause

WebKit does not focus a <button> on click. When mousedown lands on an option, the menu item that was programmatically focused earlier receives focusout, and WebKit reports event.relatedTarget === null. The handler only asks "is the new focus still inside the widget?", treats null as "focus left", and calls close() immediately — unmounting the portaled menu before mouseup, so the option's click never happens.
Chromium focuses the clicked button, so relatedTarget points inside the menu, the handler returns early, and Chrome/Edge work.
This also explains why reloading the page, restarting the browser, restarting dsh, or switching workspaces never helped: it is client code, not page state.

Evidence (reproduced in a real WebKit engine via Playwright)

Before the fix, one click produced:

mousedown tgt=SPAN:Qwen3.8-27B-AWQ-INT4  rel=null
focusout  tgt=BUTTON.option:DeepSeek-V41-Flash  rel=null
mouseup   tgt=DIV

The menu disappeared, the label stayed, and the network log contained no session/selectModel.
After the fix, the same click produced:

focusout  ...  rel=null
mouseup   tgt=SPAN:Qwen3.8-27B-AWQ-INT4
click     tgt=SPAN:Qwen3.8-27B-AWQ-INT4

session/selectModel was sent and the label switched to the picked model.

Suggested fix

Treat relatedTarget === null as "unknown", not as "focus left the widget".

packages/client/ui-model-selection (ModelSelect's onBlur):

const onBlur = (event) => {
  const next = event.relatedTarget;
  if (next === null) return; // WebKit reports null when mousedown lands on a non-focusable target, incl. our own portaled menu buttons
  if (next instanceof Node && (rootRef.current?.contains(next) === true || menuRef.current?.contains(next) === true)) return;
  close();
};

packages/client/ui-workflow-run (both settleRunBlur and settlePhaseBlur):

if (!(event.relatedTarget instanceof Node) || event.currentTarget.contains(event.relatedTarget)) return;

packages/client/ui-directory-picker-browse:

if (event.relatedTarget === null) return;
if (event.relatedTarget instanceof Node && card.contains(event.relatedTarget)) return;

Style reference: packages/client/ui-sidebar-documentpreview already starts its condition with event.relatedTarget instanceof Node && …; since null instanceof Node === false, it can never collapse on this blur. That is also the shape I would suggest standardising on.

Local verification

• Playwright WebKit: deterministic reproduction before the fix; successful pick after it (a session/selectModel request plus the updated label).
• Clicking outside the menu still closes it (handled by the existing document mousedown listener) — no regression.
• All three bundles pass node --check, and the page boots with zero console/page errors.

[xirener]

补充观察

1. 与模型、提供方无关：本地模型（qwen 路由）选不中，官方在线模型 DeepSeek-V4-Pro 同样选不中——菜单里都能看到、都能点，点完都毫无反应。这与上面「§ 根因」一致：onBlur 抢在 click 之前把菜单卸载了。
2. 会话显示的当前模型都回到了默认模型：升级后界面上所有 session（包括此前用本地模型对话过的老 session）都显示为默认模型 DeepSeek-V41-Flash。
3. IM 通道（@xmanrui/dsh-im → 飞书）表现不同：在飞书侧发起的 session 里手动切换模型会提示「切换成功」，但实际对话仍然使用默认模型 DeepSeek-V41-Flash。

第 2、3 点可能与本文的 onBlur 根因无关（分别疑似升级迁移/投影问题，以及第三方 IM 插件与宿主之间模型选择未生效）。在报告者机器上的本地复核：普通 session 的 session/selectModel 在宿主侧确实生效（下一次请求的 request/context 事件会带出所选模型），因此失败面目前收敛为 (a) 客户端点击链路、(b) IM 通道。如需要我可以就这两点分别另开 report。

---

Additional observations

1. Not model- or provider-specific: the local route (qwen) cannot be selected, and the official online model DeepSeek-V4-Pro cannot be selected either — both are visible and clickable in the menu, and clicking either does nothing. This matches the root cause above: onBlur unmounts the menu before click fires.
2. Every session shows the default model again: after the upgrade, all sessions — including older ones that previously chatted with the local model — display DeepSeek-V41-Flash, the deployment default.
3. The IM path behaves differently: in sessions created through @xmanrui/dsh-im (Feishu), manually switching the model reports success, yet the conversation still runs on the default model DeepSeek-V41-Flash.

Points 2 and 3 may be unrelated to the onBlur root cause (they look like an upgrade migration/projection issue and a third-party IM plugin issue respectively). Local verification on the reporting machine: for ordinary sessions session/selectModel is applied by the host (the next request's request/context event carries the selected model), which narrows the failure surface to (a) the client click path and (b) the IM path. Happy to file separate reports for each if useful.