# Upstream bug report

`deepseek-ai/deepseek-harness` currently has **issues disabled** (`has_issues: false`),
so this report cannot be filed through the tracker. It is kept here as:

1. a precise, reproducible description of the defect, and
2. a copy-pasteable template for whenever upstream reopens issues (or for a
   discussion thread / email to the maintainers).

---

## Draft report

**Title:** Composer: typed text invisible when backdrop overlay desyncs from
textarea value (`InputBar` two-layer coupling has no fallback)

**Component:** `packages/client/ui-conversation` → `src/client/skeleton/InputBar`

**Affected version:** `@deepseek-ai/dsh` `0.1.1-rc.2` (npm `latest`, 2026-08-21)
**Not affected:** `0.1.2-alpha.3` and later (composer rewritten on Lexical `contenteditable`)

### Summary

`InputBar` renders the draft as two stacked layers:

- `.input` — the real `<textarea>`, holding the value, deliberately painted
  invisible via `color: transparent; -webkit-text-fill-color: transparent`
- `.backdrop` — a sibling overlay with `pointer-events: none` that paints the
  formatted text the user actually reads

Every visible glyph therefore depends on the backdrop re-rendering in lockstep
with the textarea. When that synchronisation is lost, the user keeps typing into
an element that is guaranteed invisible — keystrokes land, the send button
lights up, the character counter climbs — but nothing is displayed. There is no
fallback: the composer is silently unusable.

The in-source comment acknowledges the coupling:

> the caret is the textarea's and every visible glyph is the backdrop's

but no degradation path is provided.

### Steps to reproduce

1. Run `dsh web` on `0.1.1-rc.2`.
2. Work in a long-lived session (many turns, several refreshes over its lifetime).
3. `Cmd+R` / hard-refresh the tab.
4. Type into the composer.

**Observed:** characters do not appear. The caret moves, the send button becomes
enabled, the status-bar character count increases, `@`-autocomplete still opens —
proving the value reached the textarea — but no glyphs are painted.

**Expected:** typed text is visible.

**Workaround:** creating a *new* session renders correctly, confirming the defect
is session-state dependent rather than a global failure.

### Suggested fixes

Ordered by preference:

1. **Ship the Lexical rewrite** (`0.1.2-alpha.x`) to `latest` — it removes the
   transparent layer and the backdrop entirely, which eliminates the class of
   bug rather than one instance of it.
2. **Add a degradation path for `0.1.1-rc.x`:** when the backdrop has not been
   updated for the current draft, drop the transparency on `.input` so the
   native textarea text shows through. Losing syntax highlighting beats losing
   the composer.
3. **At minimum, detect and surface it:** if the backdrop's rendered text length
   diverges from `textarea.value.length` for more than N frames, mark the
   composer as degraded and tell the user to refresh, instead of failing silently.

### Reference implementation

`lib/client.js` in this repository implements option 2 from the outside: it
probes `getComputedStyle` on every editable surface, and when the text is
painted fully transparent it restores the theme foreground colour with an
inline `!important` declaration. It self-disables as soon as the composer's
`color` becomes opaque, so it is safe to leave installed across upgrades.

---

## Notes for whoever files this

- Verify the version you are running first (`dsh --version`); if it is
  `>= 0.1.2`, this defect no longer applies and the report should not be filed.
- Include whether third-party client bundles are loaded — in the original
  report none of them were involved, which is worth stating explicitly so the
  issue is not misrouted to a plugin author.