BUG(0.1.6-alpha.2, Safari/WebKit): model picker rows unselectable by mouse — the press blurs the card with a null relatedTarget and onBlur closes it before the click

[rayseling]

Symptom

On 0.1.6-alpha.2, in Safari, no row in the composer's model picker can be selected with the mouse. Open the model chip, drill into 模型 / Model, click any row: the card closes, the model does not change, no error, no toast, and no session/selectModel request is sent. Every row is affected, not a particular provider. Chrome/Chromium is unaffected. Keyboard selection (↓ into the list, Enter) works in Safari.

Environment

• dsh 0.1.6-alpha.2 built from source, web profile, page served over plain HTTP on a trusted host.
• Reproduced headlessly in Playwright WebKit 26.5 (webkit-2311), so this is engine-level rather than a Safari preference or extension.

Evidence

Capture-phase listeners on document while clicking one row (WebKit):

event	target	inside [role=menu]	menus / rows in DOM
pointerdown	span.modelName	yes	1 / 6
mousedown	span.modelName	yes	1 / 6
mouseup	the composer input div	no	0 / 0

The card is already unmounted by mouseup, so the mouseup lands on the composer underneath and no click event is ever generated on the row — hence no handler, no RPC, no error.

Two controls, same build, same page:

• element.click() from the console (no focus change): POST /api/session/selectModel is sent and the selection applies.
• keyboard Enter on a row (focus moves within the card): same, works.

So the handler and the RPC are fine; only the real pointer sequence fails.

Root cause

packages/client/ui-model-selection/src/client/ModelSelect.tsx, the card root's onBlur:

const onBlur = (event: FocusEvent<HTMLDivElement>): void => {
  if (event.relatedTarget instanceof Node && (
    rootRef.current?.contains(event.relatedTarget) === true
    || menuRef.current?.contains(event.relatedTarget) === true
  )) return
  close()
}

When relatedTarget is null the guard's first conjunct fails and the card closes.

WebKit does not focus a <button> on mousedown. Pressing a row therefore pulls focus off whatever row currently holds it and reports relatedTarget === null, so onBlur reads "focus left the card" and calls close() during mousedown. Chromium focuses the pressed button, relatedTarget is the row itself (inside menuRef), the guard returns early, and the click completes.

Why it appears now

The onBlur guard is byte-identical to earlier releases. What changed is that the picker now hands focus to a row when a pane is drilled into (the paneFocus ref and the ?.focus() calls added with the shared menu family's keyboard model). Before that, in WebKit nothing inside the card held focus after a mouse-opened menu, so pressing a row produced no focusout and the click completed. The new explicit row focus makes the pre-existing null-relatedTarget path reachable on every mouse selection.

Any other card using the same "close on blur unless relatedTarget is contained" shape plus real focus on its rows is exposed the same way.

Suggested fix

Stop the press from moving focus, so the blur never happens. On the card element (the menuRef div):

// Pressing a card button keeps focus where it is. WebKit gives a pressed
// `<button>` no focus, so the press would pull focus off the focused row with
// no relatedTarget; `onBlur` would close the card and unmount the row before
// its mouseup, and no click would follow.
onMouseDown={(event) => {
  if (event.target instanceof Element && event.target.closest('button') !== null) event.preventDefault()
}}

preventDefault() on mousedown cancels only the focus move (and text selection); the click still fires. onBlur stays exactly as it is, presses on non-button parts of the card (group titles, the scroll track, status text) keep the browser default, and in Chromium/Firefox the only change is that a pressed row no longer takes focus before its click. The same pattern already exists in packages/client/ui-directory-picker-browse/src/client/DirectoryBrowser.tsx, whose rows suppress this focus steal on mousedown.

Why not special-case relatedTarget === null in onBlur? It keeps the card open, but focus has already fallen to body. onKeyDown lives on the component root, so once focus is on body the card stops receiving keys: after a refused selection (settleSelection only toasts) or a press released off the row, Escape and the arrow keys no longer work. It would also change Chromium, where a press on a group title currently closes the card.

Regression tests

• Component spec (jsdom): pressing a card button returns false from fireEvent.mouseDown (default prevented) and leaves focus on the drilled row, a group-title press returns true, and the row's click then selects. jsdom performs no default focus move, so this pins the mechanism, not the WebKit behaviour.
• Real WebKit (web lane): drive Playwright WebKit through the existing web scaffold, drill into the model pane, click the other row with a real pointer, and assert the trigger's label changed. Without the handler it fails (expected '选择模型，当前 Acme Think' to match /Acme Swift/); with it, it passes. The CI web lane installs only Chromium, which focuses pressed buttons and cannot observe this, so the scenario should skip where no WebKit build is installed.

---

Edited 2026-09-18: the suggested fix changed from a relatedTarget === null guard in onBlur to preventing the focus move on mousedown; the reason is in "Why not special-case…" above.

[fangzhiyu]

Independent confirmation on desktop Safari (macOS) — and a verified fix

Same symptom, same root cause, on 0.1.6-alpha.2 built from source (web profile) in desktop macOS Safari — not iOS, no extension. WebKit-only, as you found.

Capture-phase hit-testing at the pointer coordinates. The coordinates are identical on both events; only the target changes:

[pointerdown] menu connected=true  @(1706,866) -> [menuitemradio] Low row
[mousedown]   menu connected=true  @(1706,866) -> [menuitemradio] Low row
[pointerup]   menu=null            @(1706,866) -> chat message row
[mouseup]     menu=null            @(1706,866) -> chat message row

No click is dispatched, so onClick never runs: no RPC, no toast, no session event. Every row stays enabled (disabled=false, aria-checked only marks the current value), which is why nothing surfaces the loss.

A focusout with relatedTarget === null is directly observable immediately before the card disappears — the path your analysis names. Pressing and holding shows the card already gone before release, so the unmount happens during the press.

The alpha.1 → alpha.2 reachability change also reproduces independently: alpha.1 has 2 .focus() sites (the trigger restore in close(), and arrow-key moveFocus) and no paneFocus; alpha.2 has 5, including the drill target. The guard is old; the new focus step is what exposes it.

Fix

onBlur stops adjudicating a null destination. Dismissal stays with the document-level mousedown listener, which reads the event target and already returns early for targets inside the card.

Before — a null relatedTarget makes the first conjunct false, so the containment check is skipped and close() runs unconditionally:

const onBlur = (event: FocusEvent<HTMLDivElement>): void => {
  if (event.relatedTarget instanceof Node && (
    rootRef.current?.contains(event.relatedTarget) === true
    || menuRef.current?.contains(event.relatedTarget) === true
  )) return
  close()
}

After — the null case joins the two containment checks in one guard, matching the closeOutside listener just above it, and close() still runs once:

const onBlur = (event: FocusEvent<HTMLDivElement>): void => {
  const { relatedTarget } = event
  if (relatedTarget === null
    || rootRef.current?.contains(relatedTarget) === true
    || menuRef.current?.contains(relatedTarget) === true) return
  close()
}

The regression test drives that exact sequence — press the row, blur with a null destination, release, click — and asserts the selection is submitted (ModelSelect reasoning effort > keeps a row mounted across the mousedown a real pointer opens the gesture with):

const row = screen.getByRole("menuitemradio", { name: /Max/ })
fireEvent.mouseDown(row)
// The pointer transfers focus out of the trigger subtree; Safari reports no
// destination for it. The card must survive so the click can still arrive.
fireEvent.blur(trigger, { relatedTarget: null })
expect(screen.getByRole("menuitemradio", { name: /Max/ })).toBeTruthy()
fireEvent.mouseUp(row)
fireEvent.click(row)

await waitFor(() => {
  expect(select).toHaveBeenCalledWith({
    provider: "deepseek-official",
    model: "deepseek-v4-flash",
    reasoningEffort: "max",
  })
})

It fails with the guard reverted and passes with the fix:

pnpm exec vitest run --config vitest.config.ts \
  packages/client/ui-model-selection/tests/model-select.client.spec.tsx

The surrounding suite is 41 passed on the same command; pnpm run test:gui is 433 files / 6184 passed / 1 skipped.

Other cards using the same pattern

Your closing question — I searched the tree for blur/focus handlers that read relatedTarget. Three more sites; two are the same class:

site	guard	on relatedTarget === null
packages/client/ui-directory-picker-browse/src/client/DirectoryBrowser.tsx:810	if (rt instanceof Node && card.contains(rt)) return	falls through to cancelPathEdit() — cancels an in-progress path edit instead of letting the click land (gated on pathDraft !== null and document.hasFocus())
packages/client/ui-workflow-run/src/client/WorkflowRunPanel.tsx:417,424	if (event.currentTarget.contains(event.relatedTarget)) return	contains(null) is false, so it falls through and collapses the disclosure, which can unmount the pressed control
packages/client/ui-sidebar-documentpreview/src/client/office/FontNotice.tsx:77	collapses only when rt instanceof Node && !contained	no-op on null — safe

Reachability for the first two depends on whether focus lands inside their card the way the picker's drill step now makes it. Probably worth checking separately rather than assuming they are live.

[sprainJinyu]

独立复现确认 + 已验证补丁（macOS 自建 WKWebView 桌面壳场景）

我在一个自建的 macOS 桌面壳（原生 WKWebView 直接加载 dsh web 的 127.0.0.1 页面）上独立复现了本问题，症状与楼主一致：菜单能展开、点击任意模型行后菜单收起但模型不变，且整条链路上 session/selectModel 一次都不会发出；同一构建在 Chrome 下完全正常。

根因认同楼主与 fangzhiyu 的分析，并补一条定位证据：给 ModelSelect.choose / ModelDirectory.select 加埋点后，WebKit 下的点击连 choose 的第一条记录都没有——说明行的 onClick 从未执行，即菜单在 click 落地前已被卸载；而收起动作来自 onBlur（relatedTarget === null 被判为"离开组件"）。Chromium 点 button 会聚焦，relatedTarget 落在组件内走早退，因此免疫。点燃点确为 0.1.6 周期内"drill 时显式 .focus()"的键盘交接改动：在此之前菜单打开期间没有元素持焦，这颗雷不会响。

修法上，除 fangzhiyu 的"null 并入 containment guard"外，我们采用了一种等价但更显式的方案，供维护者取舍：在 capture 阶段记录"本次 mousedown 是否起于组件内部"（root 或 portal 菜单），onBlur 遇到这种失焦直接返回，把结果交给随后的 click（或既有的 outside-mousedown 关闭）决定，并在 document 的 click capture 上复位标记。好处：

• 不依赖"引擎是否聚焦 button"的平台差异，WebKit / Chromium 语义都正确；
• 保留"纯键盘失焦（如 Tab 出组件）仍关闭菜单"的既有行为，不把 blur 关闭整体废掉；
• 对 portal 容器、未来浮层实现的变化不敏感。

已附两条回归测试锁死双向行为：① 组件内 mousedown + null relatedTarget 失焦后，click 仍提交选择；② 无 mousedown 的纯失焦仍关闭菜单。（fork 内 commit：fix(ui-model-selection): keep the model menu open through a webview null-blur）

另补充一个排查中发现的独立缺陷（与本帖症状叠加、显著放大排查难度）：认证后的 index.html 200 响应没有任何 cache-control，可被启发式缓存；而插件模块按内容哈希 rev 以 immutable, max-age=1y 服务。WebKit 的 HTTP 缓存因此可能钉住旧 index（旧 rev）→ 旧插件模块，表现为"重载/重启后依旧坏"。我们已给 HTML 响应加 no-store（commit：fix(host-frontend-static): never cache the index HTML）。建议单独立帖或并入修复 PR。

补丁已在一个公开 fork 分支上备好（基于当前 master，含上述两条回归测试，clean install 下 21/21 通过）：

• 分支：https://github.com/sprainJinyu/deepseek-harness/tree/fix/webkit-blur-index-cache
• 8fa1446b2e fix(ui-model-selection): keep the model menu open through a webview null-blur
• a0f0eab97f fix(host-frontend-static): never cache the index HTML

维护者可直接 cherry-pick 这两个提交；如更希望以 PR 形式提交、或希望我把守卫扩展到 fangzhiyu 点名的其余同模式组件，说一声我即补上。

[IridiumMaster]

Independent confirmation on desktop Safari with our source-built 0.1.6-alpha.2 deployment: mouse selection closed the model/effort menu before the click applied, while keyboard selection worked.

We deployed the suggested focus-preservation approach on the portaled menu:

onMouseDown={(event) => {
  if (event.button === 0) event.preventDefault()
}}

The existing blur/outside-dismissal logic stays unchanged. Regression tests reproduce the Safari-style blur ordering for both model and effort selection and pass with the fix; the GUI suite passed (6,183 tests, one skipped), as did focused model/effort browser tests. Live Safari mouse checks also passed: switched between two models and back, then High → Low → High reasoning. Those live checks were browser-automated, not a claim of manual human testing.

Thanks for documenting the root cause—this resolved the issue in our deployment.

[dsh-community-assistant[bot]]

Thanks for the report.

[satellite13]

Follow-up for 0.1.7-rc.1 (current master): the onMouseDown preventDefault() proposed here is in the tree (6613660223, 06ef26a80f, 2026-09-20) and does keep row clicks alive in WebKit. It only covers presses whose target is a <button>, though — a press inside the card on a non-control (provider heading, card padding, list scrollbar) still emits focusout(relatedTarget === null) and unmounts the card before the click, in Chromium as well as WebKit.

Narrower rule with tests and a branch: press-held flag (set on pointerdown capture, cleared on pointerup/pointercancel/window blur) plus refocusing the control the press took focus from, instead of ignoring every destination-less blur — details, probe table and links in #7601 (comment).