Web UI broken on older mobile browsers: AbortSignal.any is not a function

[klnirvana]

Environment

• dsh version: 0.1.0-rc.6 (also reproduced on 0.1.1-rc.2)
• Client: older mobile browser / Android WebView (Chromium < 116, no AbortSignal.any); browser version unchanged during the whole period
• Server: Windows 10, Node 24, dsh web on 127.0.0.1:3080

Symptom

The Web UI loads and renders normally on the phone, but sending a chat message does nothing. Console shows:

AbortSignal.any is not a function

A desktop browser with a recent Chrome works fine.

Root cause

@deepseek-ai/dsh-client-connection/lib/client.js calls AbortSignal.any() / AbortSignal.timeout() without feature detection in postJson() (the shared POST leg of the C→S RPC carrier). AbortSignal.any requires Chromium 116+ / Safari 17.4+, so on older mobile browsers/WebViews the very first RPC that carries a caller signal (i.e. sending a message) throws, breaking the chat composer while the rest of the UI keeps rendering. Passive calls without a caller signal only need AbortSignal.timeout (Chromium 103+), which is why browsing sessions still worked on the same browser.

What I ruled out

• Third-party plugins (dshmarket / dsh-genui / dsh-at-file / dsh-better-sidebar / dsh-chat-import): their only AbortSignal.any uses are either host-side Node code (dshmarket lib/gist.js) or guarded with typeof AbortSignal.any == 'function' (dsh-genui's bundled three.js). None of their browser bundles call it unguarded.
• Network path: API trust fence, Host/Origin checks and WebSocket were all verified working; PC browser on the same server never had the issue.

Remaining puzzle

On the same dsh version (0.1.0-rc.6) and the same phone browser, sending reportedly worked at first and broke later — possibly a stale cached frontend bundle masking the issue initially. Mentioning in case it hints at a second variable (bundle caching / service worker?).

Workaround (confirmed working)

Injecting a small polyfill for AbortSignal.any / AbortSignal.timeout before the module entry in the served index.html fully restores mobile use:

if (typeof AbortSignal !== 'undefined') {
  if (typeof AbortSignal.any !== 'function') {
    AbortSignal.any = function (signals) {
      var c = new AbortController();
      for (var i = 0; i < signals.length; i++) {
        (function (s) {
          if (s.aborted) { c.abort(s.reason); return; }
          s.addEventListener('abort', function () { c.abort(s.reason); }, { once: true });
        })(signals[i]);
      }
      return c.signal;
    };
  }
  if (typeof AbortSignal.timeout !== 'function') {
    AbortSignal.timeout = function (ms) {
      var c = new AbortController();
      setTimeout(function () { c.abort(new DOMException('The operation timed out.', 'TimeoutError')); }, ms);
      return c.signal;
    };
  }
}

Suggestion

Ship the polyfill at build time, or feature-detect and fall back, so older mobile browsers keep working.

[argszero]

Verified against the latest master (b150a551b8, v0.1.1-rc.2) — the exact call sites you name are unchanged and unfixed, and this is the browser-side half of a two-ended family I traced on the Node side in #3520. Confirmed + design below.

Source confirmation (rc.8 == rc.2, unfixed)

• packages/host/apiproxy/src/fetch/client.ts:315-316 — postJson merges the caller signal with the instance timeout via AbortSignal.any([AbortSignal.timeout(this.timeoutMs), signal]) with no feature detection. Identical on rc.2 master (git show origin/master confirms :315-316 unchanged).
• Your rule-out matrix is sound: the only unguarded browser-side uses are in this postJson leg; plugin bundles either run host-side Node or guard with typeof checks.
• The "worked at first, broke later" puzzle is almost certainly stale-bundle caching (the symptom's onset = the moment the browser fetched the current bundle). A second variable would need the same browser to break without a bundle change — unlikely given the deterministic throw at the first caller-signal RPC.

Family closure: #3520 (Node) + #3912 (browser) = one missing feature-detect

In #3520 I fingerprinted the Node side: AbortSignal.timeout (Node 17.3+) and AbortSignal.any (Node 20.3+/18.17+) were introduced at different points, so "timeout works but any throws" uniquely narrows the running Node to 17.3–20.2 — a runtime mismatch (shell node ≠ bundled node). Your report completes the browser half: timeout = Chromium 103+, any = Chromium 116+ (Safari 17.4+), so Chromium 103–115 / WebView is exactly the "timeout available, any missing" window on the client side. One root cause across both ends: an unguarded dependency on AbortSignal.any in a code path that also runs in older environments.

Fix design (feature-detect + graceful degradation, ~6 lines)

In postJson, gate the merge on availability:

const requestSignal = timeoutPolicy === 'default'
  ? signal === undefined
    ? AbortSignal.timeout(this.timeoutMs)
    : typeof AbortSignal.any === 'function'
      ? AbortSignal.any([AbortSignal.timeout(this.timeoutMs), signal])
      : signal  // old browser: keep caller cancellation, drop the transport deadline
  : signal

Notes:

1. The degraded branch (: signal) is exactly the 'caller-signal-only' semantic that already exists as UnaryTimeoutPolicy for host.pickDirectory (client.ts:231/:439) — so on Chromium 103–115 a bounded call degrades to the user-paced posture instead of throwing. That is the correct fail-safe: prefer no deadline over a broken first message.
2. AbortSignal.timeout is safe to keep (Chromium 103+ ≥ the any floor); if you want to cover even older engines, gate it too — but that would require the caller-signal-only branch to also handle the no-signal case, so keep the scope at any unless you have evidence of sub-103 clients.
3. Same pattern should be applied to any other browser-bundled AbortSignal.any use that a future audit finds — grep the web bundle surface, not just the apiproxy client.

Your polyfill workaround is the right user-side stopgap

Injection before the module graph loads is the correct interception point; the official fix (feature-detect) makes the polyfill unnecessary. Worth noting for maintainers: the two-ended family means a regression test should exercise the no-AbortSignal.any path (delete the global, call postJson with a signal, assert no throw + caller cancellation still works) — one test covers both the Node-side runtime mismatch and the browser-side window.

[shikomin]

感谢！非常有用！公司电脑的chrome版本太低，也碰到这个问题了！

[ttbj2023]

Another data point, this time WebKit — and a stricter one: Safari ≤ 17.3 never reaches "connected" at all; the failure happens earlier than the postJson() leg.

Env: dsh 0.1.2-rc.1 behind nginx; iPad Safari 16.6 (iPadOS 16.6 desktop-mode UA — same WebKit family as macOS Ventura Safari 16.x).

New call site that kills the whole connection, not just message sending: packages/api/gateway/src/client/remote-events.ts:128

async pumpEvents(signal, ready) {
    const failed = new AbortController();
    const generationSignal = AbortSignal.any([signal, failed.signal]);  // ← throws on Safari <17.4, before the first WS frame
    const source = this.openStream(REMOTE_EVENT_STREAM_ENDPOINT, REMOTE_EVENT_STREAM_PAYLOAD, generationSignal)

On Safari 16.6 the generation throws before the $events stream opens, so /api/remote.mux completes the handshake (101) but the client sends zero frames, closes, and retries with backoff — the UI stays at "connecting…" forever and no /api POST is ever issued (stricter than the composer-only symptom in the OP).

Evidence: nginx byte-level logging showed every attempt from the iPad ≈ handshake-only upstream bytes, while a still-open tab running the older cached bundle (same device, pre-update build) held normal multi-minute connections with frames flowing — a natural A/B pinning it to the client bundle. A minimal WS probe through the same nginx proxy also passed on the device, exonerating network/TLS/proxy.

Promise.withResolvers (same compat floor: Safari 17.4) is also used unguarded in browser bundles:

• packages/extensions/cordis-client-runner/src/client/timer.ts:86,135
• packages/client/ui-approval/src/client/index.ts:52 and contract/slots.ts:100
• packages/client/ui-user-questions/src/client/index.ts:64 and contract/slots.ts:140
• inline boot markup served in index.html: packages/host/webserver/src/injections.ts:86 — (globalThis.__DSH_BOOT_READY__ ??= Promise.withResolvers()).resolve()

Extending the boot polyfill suggested above with Promise.withResolvers (~6 lines) fully restores Safari 16.x — verified on-device. Compat floor for both APIs: Safari 17.4 / Chrome 119 / Firefox 121.

(See also the community patch thread #1050.)