[BUG] Web composer: typed text / whole input box can disappear (3 root causes + fix)

[raktim-mondol]

Symptom

Reported by a user running the web UI: while typing in the composer, the typed text disappeared, and at times the entire input box vanished.

What I found

I could not reproduce the exact trigger after fairly extensive attempts (fresh/old sessions, slash and @-mention flows, undo storms, paste, offline/reconnect, swapping server versions under a live tab, stale localStorage, dark mode, narrow/short viewports, a live streaming turn, and a ~1,300-step randomized interaction test). But auditing the composer code in packages/client turned up three real defects, each of which independently produces one of the reported symptoms:

1. A crashed composer renders as nothing. SlotErrorBoundary (and the dry-cell / root outlets) in packages/client/web-react/src/scoped-slots.tsx caught a render error in a slot entry and replaced it with an empty <div data-slot-error> — a silent void with only a console.error as a trace. If anything in the composer's render tree throws (a bad projection value, a plugin entry crash, etc.), the whole input box disappears with zero on-screen indication that something failed, and no way to recover short of a reload.

2. The composer can stay invisible indefinitely while a session loads. ConversationRoot's "settling" phase (packages/client/ui-conversation/src/client/skeleton/ConversationRoot.tsx) hides the composer seat (visibility: hidden) while a session's history replay is in flight, to avoid a hero/docked layout flash. That hide had no time bound — a slow or stalled open (large session, flaky connection, server restart mid-load) left the composer invisible for as long as the open never settled.

3. One Ctrl+Z could wipe an entire message. InputMachine's single-char typing undo-merge window (packages/client/ui-conversation/src/client/input/machine.ts) re-anchored on every keystroke instead of at the run's start, so steady typing coalesced an entire message — no matter how long — into one undo transaction. A single Ctrl+Z (a common typo-correction reflex) could delete everything just typed, which reads exactly like "my text vanished."

Fix

• Crash faces are now visible ("This panel failed to render (…)") with a Restore action that remounts the boundary in place, or Reload for dry cells that have no live entry to remount.
• The settling hide is now capped at 3s; past that the seat renders in the docked posture and self-corrects once the open lands.
• The undo merge window now anchors at the run's first keystroke, so one undo never reverts more than one window's worth (default 1s) of typing.

Added unit tests for all three: a real crashing entry mounted through SlotErrorBoundary asserting the visible face + in-place Restore recovery, a fake-timer test asserting the settling hide expires at the bound, and a merge-window test asserting steady typing across the window boundary splits into separate undo transactions. Full existing suite for both touched packages (ui-conversation, web-react) still passes (456 tests). Also manually verified live against a built dsh web instance (bounded-undo behavior, no regression in normal typing/session-switching) using agent-browser.

Per CONTRIBUTING.md I'm not opening a PR — posting the diff here instead in case it's useful:

Fork branch: https://github.com/raktim-mondol/deepseek-harness/tree/fix/web-composer-draft-loss
Diff: raktim-mondol/deepseek-harness@master...raktim-mondol:deepseek-harness:fix/web-composer-draft-loss

Happy to expand on any of the three or split them apart if that's more useful for triage.

[moonquake2004]

All three verified in the installed 0.1.0-rc.6 build — thanks for the precise line refs, they match: defect 2's settling hide (visibility:hidden on the composer seat while openState === "loading", no timeout) is confirmed in client.js (settling = sessionId && composerPhase === "blank" && openState === "loading"; phase → "settling" → visibility:hidden), defect 1's slot-error boundary is in dsh-client-web-react, and defect 3's 1s undo-merge window is in the input machine.

One real-world amplifier worth adding: defect 2 is not just a flaky-connection issue — it hits large sessions hard. Our live web profile is ~530k events / ~18MB decoded (the same scale as #1550's cold-materialization cases), and the unbounded settling hide means the composer can sit invisible for a long time while that history replay settles. So "the input box vanished" for a heavy-session user can be this defect + slow open, on top of the #1051 composer IME issues. The 3s cap is exactly the right bound — and it's also why the S11 whole-session scan (our offline doctor, #1534) flags oversized sessions: they cost visibility time, not just memory.

Solid triage + tests — this deserves upstream attention.

[kkishapppy]

Same class of issue confirmed on our side too 鈥?real-world occurrence, not just audit:

Observed symptom (Brave PWA, DSH 0.1.0-rc.6, genui 0.8.4): the composer intermittently does not mount while the message list and running-task state render fine; it may appear on its own after 1鈥?s, and Ctrl+R reliably restores it. Session data is never affected. A diagnostic pass (isolated headless Brave over CDP, both 2079脳1187 and 2106脳658 viewports) reproduced the recovery path but could not reproduce the intermittent trigger 鈥?consistent with a slot-registry lifecycle race rather than a deterministic layout bug. Blue skin and short viewport were ruled out.

One amplifier worth linking: #2210 (posted today) describes the same slot system failing harder 鈥?a SlotErrorBoundary permanent abdicate (process-wide abdicated WeakSet) after a draft-edit render error, leaving the composer gone with no recovery short of reload. That looks like defect 1's crash face being non-recoverable in the single-cell case, which is arguably a worse variant of the same root cause. Worth aligning the fix for both (#1614's Restore/Reload crash faces + a non-permanent abdicate policy).

Question for upstream: is there a timeline for getting the three fixes (visible crash face, 3s settling cap, bounded undo window) into mainline? The fork diff (raktim-mondol/deepseek-harness:fix/web-composer-draft-loss) has been sitting since 08-14 and rc.6 users are hitting these live.

[brianivander]

The text that I'm writing is all not visible. Even when I change theme to black it same, the text also not visible.