[Bug] Web UI history never loads on Firefox-engine browsers (infinite "Loading history…") — Firefox-only failure in lossless-JSON validation

[khanecho]

Bug description

On the web UI, opening a session whose trajectory contains assistant raw chunk records
(any session after a normal agent turn) never finishes loading in Firefox-engine
browsers (Firefox, Zen). The history pane stays at "Loading history…" forever; the
client console logs a subscriber failure caused by the assistant-stream chunk validator:

[session-controller] event feed subscriber failed:
TypeError: Assistant stream raw chunk must be a lossless JSON object
(cause: Assistant stream chunk must be losslessly JSON-serializable)

The same server, the same session, and the same profile work fine in Chromium-family
browsers (Chrome, Brave, Edge). The Node-based TUI/SDK are unaffected.

Environment

• dsh: git master @ d347e70390 (the v0.1.3-alpha.1 pre-release build); reproduced
  on a zero-plugin core-only profile as well, so plugins are not involved.
• Browsers: Firefox (Linux, current ESR/stable line) and Zen — fail;
  Chromium-family — fine.
• First observed 2026-09-04/05; not yet present in any npm release (see "Why it went
  unnoticed").

Steps to reproduce

1. Run the web UI from master (d347e70390) or the v0.1.3-alpha.1 build.
2. In Firefox (or Zen), open any session that contains an agent turn with assistant
   stream data (i.e. any real session created by this build).
3. The history area stays on "Loading history…" indefinitely; the console shows the
   TypeError above. Chromium on the same URL loads the same session normally.

Root cause

packages/util/values/src/index.ts, hasIntrinsicConstructor() (lines 18–31), decides
whether a prototype is a realm-owned intrinsic by comparing the exact string form of
its constructor:

&& Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`

This assumes the V8 formatting of native functions, which is single-line. Firefox
formats natives across lines:

Measured live for this report (headless Firefox 1xx and Chromium, same machine):

Firefox (SpiderMonkey): "function Object() {\n    [native code]\n}"   // multiline, exact equality fails
Chromium (V8):          "function Object() { [native code] }"         // single line, exact equality holds

The ECMAScript spec leaves the built-in (native) function string
implementation-defined — MDN explicitly warns its content "may be
implementation-defined" — so formatting is not guaranteed to match V8 on any
engine (MDN,
es-discuss).
SpiderMonkey's multiline output is confirmed above; Safari/WebKit was not
available for measurement, but the proposed fix is engine-agnostic (whitespace
normalization), so any engine that differs from V8 only in whitespace is covered
by the same change.

Consequently, on Firefox-engine browsers every plain object fails
isIntrinsicObjectPrototype(), snapshotJsonValue() returns undefined for ordinary
JSON data, and the client-side assistant-stream validation (raw chunk records are
required to be lossless JSON) throws — so history rendering aborts before the first
message appears.

History: the exact-string comparison was consolidated into the new
dsh-util-values package on 2026-08-30 (6c53fe6e2a,
"refactor(values): make shared primitives duplicate-install safe"). It became
user-visible when the client-side chunk validator landed on 2026-09-02
(f99b06eaed, "feat(session)!: embed assistant streams in format v2", 0.1.3 material).

Why it went unnoticed so far

The affected client code has not shipped in any npm release yet. I checked the
published client bundles (dsh-client-ui-trajectory, dsh-client-connection,
dsh-api-session-controller, dsh-client-ui-chat) in 0.1.2-alpha.5 and
0.1.2-rc.1 (npm latest): they contain neither the chunk validator nor the
intrinsic check. Only the master line / the GitHub pre-release v0.1.3-alpha.1
(2026-09-04) carries it, so the affected audience is small. Once 0.1.3 reaches npm,
every Firefox-engine web-UI user will hit this. (Host-side copies of the same
pattern exist in packages/core/tools/src/json-schema.ts, packages/extensions/ cordis-host-runner/src/guard.ts and packages/code-runtime/.../src/worker-json.ts;
they only run under Node/V8 today, so they are latent, not breaking.)

Suggested fix (one line)

Normalize whitespace before comparing; this makes Firefox behave exactly like V8 —
genuine FF-formatted natives now pass, and nothing is accepted that was not already
accepted under V8 formatting (the check is a duplicate-install/cross-realm heuristic,
not a security boundary; whitespace-collapsed lookalikes were already equal under V8):

&& Function.prototype.toString.call(constructor).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`

Ready-to-apply patch (source only, applies cleanly onto d347e70390; the full
patch file is available on request) — inline below. Happy to open a PR through
whatever process you prefer (CONTRIBUTING.md says external PRs are not accepted
at the moment).

diff --git a/packages/util/values/src/index.ts b/packages/util/values/src/index.ts
index 78a2cbb493..bf27288f74 100644
--- a/packages/util/values/src/index.ts
+++ b/packages/util/values/src/index.ts
@@ -22,7 +22,9 @@ function hasIntrinsicConstructor(prototype: object, name: 'Array' | 'Object'): b
   try {
     return constructor.name === name
       && constructor.prototype === prototype
-      && Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`
+      // Engine-tolerant: Firefox formats native source across lines
+      // ("function Object() {\n    [native code]\n}") while V8 keeps one line.
+      && Function.prototype.toString.call(constructor).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`
   } catch {
     return false
   }

Verification performed

• Live engine measurements (headless Firefox + Chromium, this report): Firefox
  returns "function Object() {\n [native code]\n}" — exact single-line
  equality false, equality after /\s+/gu normalization true; Chromium
  returns the single-line form with exact equality true.
• Spec/documentation: native function strings are implementation-defined
  (MDN Function.prototype.toString);
  engine formatting differences are a known es-discuss topic
  (forward-incompatible Function.prototype.toString requirement).
• Headless-Firefox repro against a live master server: deterministic failure on
  session open (attempt 0) with the quoted TypeError; the same run under Chromium
  renders history cleanly.
• With the one-line fix applied (source + rebuilt client bundles), Firefox loads the
  same sessions normally; a full-snapshot validation that previously aborted now
  passes.
• Safari/WebKit was not available for measurement; the fix normalizes whitespace, so
  it covers any engine whose native-string formatting differs from V8 in whitespace.
• No existing report found: GitHub issue search (multiple phrasings, EN/中文) and
  Discussion search (firefox, "Loading history", "lossless JSON", engine names)
  return nothing matching this signature. Related-but-different threads:
  #4513 /
  #1550 /
  #3408 (large or
  corrupt sessions) and
  #4919
  (Firefox WebSocket mixed-content settings, unrelated).

---

中文摘要

Web UI 在 Firefox/Zen 等引擎上打开含 assistant 流数据的会话时永远停在
“Loading history…”。根因在 packages/util/values/src/index.ts 的
hasIntrinsicConstructor：它用 Function.prototype.toString 的精确字符串
判断原生构造器，只适配了 V8 的单行格式；Firefox 会输出多行
(function Object() {\n [native code]\n})，导致所有普通对象被判为非法，
客户端 chunk 校验抛 TypeError: Assistant stream raw chunk must be a lossless JSON object。该代码 2026-08-30 引入 (6c53fe6e2a)，2026-09-02 客户端校验
(f99b06eaed) 使其可见；目前只存在于 master / v0.1.3-alpha.1（npm 尚未发布），
0.1.3 发布后所有 Firefox 引擎用户都会受影响。修复：比较前归一化空白
(.replace(/\s+/gu, ' '))，使 Firefox 与 V8 行为一致。

[argszero]

Confirmed against master @ d347e70390 — root cause holds, and I verified the fix must land in 4 places, not 1, to keep this from re-appearing.

The exact-string comparison is duplicated across the codebase:

1. packages/util/values/src/index.ts:25 — the acute one. This is what the client-side chunk validator (feat(session)!: embed assistant streams in format v2, f99b06eaed) exercises, so Firefox/Zen breaks here first. ✅ covered by your one-line patch.
2. packages/core/tools/src/json-schema.ts:98 — same Function.prototype.toString.call(constructor) === \function ${name}() { [native code] }`. This runs under Node/V8 today, so it's latent — but json-schema.ts` is the shared "enforced JSON Schema subset" used by tool outputs / PTC mode / subagents / workflows.
3. packages/extensions/cordis-host-runner/src/guard.ts:50 — the host-runner VM-boundary façade. Also latent under Node, but it defines what a plugin's shadowed apply may pass.
4. packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts:90 — a variant that applies intrinsicReflectApply(intrinsicFunctionToString, constructor, []) instead of Function.prototype.toString.call(...), to dodge prototype tampering inside the Worker. Same exact comparison, same engine-sensitivity.

The consolidation opportunity is the real value here. Sites 2 and 3 carry /* jscpd:ignore-start ... this realm boundary mirrors the session-owned ... intrinsic test */ — i.e. they deliberately keep a private copy rather than importing from @deepseek-ai/dsh-util-values. Both mirror hasIntrinsicConstructor + isIntrinsicObjectPrototype. If the canonical hasIntrinsicConstructor is exported from dsh-util-values (fix applied once at index.ts:25) and sites 2/3/4 import that helper instead of re-declaring it, then:

• the whitespace-normalization fix propagates to every consumer automatically, and
• the 4th copy can never drift past the fixed one again (which is exactly the failure mode the jscpd:ignore-start mirrors warn about).

The one-line .replace(/\s+/gu, ' ') is engine-agnostic and safe: whitespace-collapse only makes more values pass (it can never reject something V8 currently accepts), and this check is a duplicate-install / cross-realm heuristic, not a security boundary — so your "no new acceptance" reasoning holds.

One caution on your fire-and-forget framing: you scoped this as "only the master / v0.1.3-alpha.1 line carries it, so the audience is small." That's accurate for the client exposure today, but sites 2/3/4 already ship in 0.1.2-rc.1 (npm latest) as the latent Node-side copies. If only values gets fixed and the shared helper isn't exported, the moment any of those surfaces runs under a browser engine (e.g. a future client-side schema parse, or a Web Worker host for code-runtime) the same TypeError returns silently. Fixing all four in one commit + extracting the helper is the durable solution.

Given upstream external PRs aren't accepted at the moment, this is a solid reference-diff candidate — happy to help draft the 4-site patch + helper extraction if the maintainers open a path.

[khanecho]

Thanks for the detailed verification — all four sites check out on my side too, and I've folded them into one apply-clean reference diff below.

Confirmed against d347e70390 and the npm tarballs:

• packages/util/values/src/index.ts:25 — acute (client-side chunk validator path), covered.
• packages/core/tools/src/json-schema.ts:98 — latent, present in rc.1 as dsh-tools lib/types/json-schema.js and lib/index.js.
• packages/extensions/cordis-host-runner/src/guard.ts:50 — latent, present in rc.1 as dsh-cordis-host-runner lib/types/guard.js and lib/index.js.
• packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts:90 — the captured-intrinsic variant (intrinsicReflectApply(intrinsicFunctionToString, ...)), present in rc.1 as both lib/index.js and lib/worker.cjs.

One nuance on the consolidation direction: site 4 cannot simply import the canonical helper. worker-json.ts is a deliberately dependency-free worker closure (its jscpd:ignore-start comment: "the source worker mirrors session JSON helpers without workspace runtime imports"), and it captures Function.prototype.toString at load time specifically so code running inside the worker cannot tamper the intrinsic and spoof the check. Importing hasIntrinsicConstructor from @deepseek-ai/dsh-util-values there would reintroduce both a runtime dependency and the tamper surface. The whitespace normalization applies equally well to the captured intrinsic's output, so I'd keep site 4 local (one-line fix in place) and consolidate only sites 2–3 — both already carry runtime edges to dsh-util-values (json-schema.ts imports assertNever/isJsonValue; cordis-host-runner's inspect-registry.ts imports snapshotJsonValue), so exporting hasIntrinsicConstructor + isIntrinsicObjectPrototype (and the array/object-prototype helpers they mirror) from values would let those two import it with no new dependency class. Exporting helpers from values is an API-surface call for the package owner — happy to prepare that variant too if useful. (The String(...) wrapper at site 4 keeps the captured intrinsic's unknown-typed call typecheckable.)

Reference diff (applies cleanly onto d347e70390; four sites, one engine-tolerant expression each):

diff --git a/packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts b/packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts
index 40dcc2e1e8..52ab4a3079 100644
--- a/packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts
+++ b/packages/code-runtime/code-runtime-worker-thread/src/worker-json.ts
@@ -87,7 +87,7 @@ function hasIntrinsicConstructor(prototype: object, name: 'Array' | 'Object'): b
   try {
     return constructor.name === name
       && constructor.prototype === prototype
-      && intrinsicReflectApply(intrinsicFunctionToString, constructor, []) === `function ${name}() { [native code] }`
+      && String(intrinsicReflectApply(intrinsicFunctionToString, constructor, [])).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`
   } catch {
     return false
   }
diff --git a/packages/core/tools/src/json-schema.ts b/packages/core/tools/src/json-schema.ts
index c064fb294c..f2d3e113a1 100644
--- a/packages/core/tools/src/json-schema.ts
+++ b/packages/core/tools/src/json-schema.ts
@@ -95,7 +95,7 @@ function hasIntrinsicConstructor(prototype: object, name: 'Array' | 'Object'): b
   try {
     return constructor.name === name
       && constructor.prototype === prototype
-      && Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`
+      && Function.prototype.toString.call(constructor).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`
   } catch {
     return false
   }
diff --git a/packages/extensions/cordis-host-runner/src/guard.ts b/packages/extensions/cordis-host-runner/src/guard.ts
index a70e47ef55..98264e10c8 100644
--- a/packages/extensions/cordis-host-runner/src/guard.ts
+++ b/packages/extensions/cordis-host-runner/src/guard.ts
@@ -47,7 +47,7 @@ function hasIntrinsicConstructor(prototype: object, name: 'Array' | 'Object'): b
   try {
     return constructor.name === name
       && constructor.prototype === prototype
-      && Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`
+      && Function.prototype.toString.call(constructor).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`
   } catch {
     return false
   }
diff --git a/packages/util/values/src/index.ts b/packages/util/values/src/index.ts
index 78a2cbb493..bf27288f74 100644
--- a/packages/util/values/src/index.ts
+++ b/packages/util/values/src/index.ts
@@ -22,7 +22,9 @@ function hasIntrinsicConstructor(prototype: object, name: 'Array' | 'Object'): b
   try {
     return constructor.name === name
       && constructor.prototype === prototype
-      && Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`
+      // Engine-tolerant: Firefox formats native source across lines
+      // ("function Object() {\n    [native code]\n}") while V8 keeps one line.
+      && Function.prototype.toString.call(constructor).replace(/\s+/gu, ' ') === `function ${name}() { [native code] }`
   } catch {
     return false
   }

[npk0441-lang]

Independent reproduction from a second environment (Windows 11 + Firefox, local build of dsh-v0.1.3-alpha.1). Same symptoms, same error chain, same root cause — I can confirm the exact-string comparison in hasIntrinsicConstructor fails on SpiderMonkey's multiline native-function formatting, which makes snapshotJsonValue reject every plain object.

We also fixed and verified all four sites in one pass (util-values + the three latent host-side copies, including the captured-intrinsic variant in worker-json.ts with the String(...) wrapper). After a full rebuild, Firefox loads history, renders replies, and pages normally; Chromium shows no regression. The whitespace-normalization approach and the reference diff here match what we applied locally, which is a good sign.

A Chinese-language write-up (marked as a duplicate of this thread) is at #5709 for anyone who prefers it. Thanks for the thorough report — hopefully the maintainers can land a fix (or open a PR path) before 0.1.3 ships to npm.

I and Openclaw fixed this problem without noticing this thread and wasted 2 hours and 2$ on this shit. We should check Github first😭