[0.1.6-alpha.2] Model/Effort menu drops taps on iOS — new drill focus + onBlur closes the panel before click

[tigerwho1888]

Summary

On a touch device (iPhone, iOS Safari, dsh web served over a private network), the composer's model menu cannot be used: tapping Model or Effort opens the list correctly, but tapping any model/effort row does nothing — no selection, no toast, no model/selection event on the Host. The panel simply closes. The same selection issued from the Host (session/selectModel over the /api RPC) succeeds for the same Session, and the same menu works on desktop.

This is a regression in 0.1.6-alpha.2: with 0.1.6-alpha.1 on the same device the menu worked (see "Why alpha.2" below).

Component

@deepseek-ai/dsh-client-ui-model-selection — ModelSelect (lib/client.js).

Reproduction

1. dsh web on the machine, page opened in iOS Safari on the phone.
2. Open the composer's model menu (the pill in the tool row).
3. Tap Model → the model list opens (94 rows in my deployment, three provider groups).
4. Tap any model row → nothing happens: no session/selectModel call, no toast, and the menu is closed afterwards. Same for Effort → level rows.

Measured tap trace from the device (temporary read-out, capture-phase pointerdown):

02:02:01 tap <button> "ModelDeepSeek-V4.1-Flash" menu=y rows=0    -> pane drilled
02:02:04 tap <button> "DeepSeek-V4-Pro"         menu=y rows=94   -> nothing
02:02:09 tap <button> "EffortHigh"              menu=y rows=0    -> pane drilled
02:02:10 tap <button> "Max"                     menu=y rows=4    -> nothing

pointerdown proves the finger lands on the right button; the click never runs, and no selection starts (no entry in the Host session log).

Root cause

alpha.2 added the focus step that runs after drilling into a pane: the [open, pane] effect calls .focus() on the checked [role="menuitemradio"] row (paneFocus.current = "drill").

The next tap on another row fires focusout with event.relatedTarget === null on iOS, because mobile Safari does not hand focus to a tapped <button>. That reaches:

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

which reads it as "focus left the menu" and calls close() — so the panel (a createPortal on document.body) unmounts between touchstart and the click, the clicked button disappears, and its React onClick never runs. Desktop sets relatedTarget to the tapped cell, so it never takes this path.

Version comparison of dsh-client-ui-model-selection/lib/client.js:

build	drill focus (paneFocus.current = "drill")	.focus() calls	size
0.1.6-alpha.1 (worked)	0	2	43,291 B
0.1.6-alpha.2 (broken)	1	5	47,831 B

So the closure rule is old, but until alpha.2 nothing inside the menu took focus, and on iOS there was no focus change to misinterpret.

Suggested fix

Ignore a focus change that carries no relatedTarget (the touch case), or drop the onBlur close entirely — the menu already closes on an outside pointerdown (closeOutside), on Escape, and after a selection:

const onBlur = (event) => {
  if (event.relatedTarget == null) return;   // touch: no focus hand-off
  if (event.relatedTarget instanceof Node && (rootRef.current?.contains(event.relatedTarget) === true || menuRef.current?.contains(event.relatedTarget) === true)) return;
  close();
};

(I run that one-line change locally; it restores selection on iOS. Happy to send a PR if you prefer a patch to a Discussion.)

[fangzhiyu]

Same root cause, confirmed end-to-end on the desktop counterpart of this case.

I reproduced it in desktop macOS Safari (WebKit, no touch, no extension) and posted the analysis, a verified fix with a regression test, and an audit of the other cards that share the relatedTarget pattern in the WebKit thread:
#6997 (comment)

Two points specific to this iOS report:

• Your .focus() and bundle-size comparison matches what I measured at source level: 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 closure rule is old; the new drill focus is what makes it reachable on WebKit. Your conclusion holds.
• The fix is engine-level rather than touch-specific: stopping onBlur from reading a null relatedTarget as "focus left the card" covers the iOS tap path and the desktop mouse path with one change, which is the direction you suggested.