You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v2 prompt composer: typing slows down proportionally to the number of lines in the draft #40225
Typing into the v2 prompt composer (packages/session-ui's PromptInputV2) gets progressively slower as the draft accumulates more lines. Each input event re-walks the entire contenteditable DOM (parsePromptInputV2Editor) and recomputes the caret offset via Range.toString(). The editor never flattens the DOM nodes it accumulates from typed/pasted line breaks (the browser inserts one <div> per line, and the local-input path skips re-rendering), so per-keystroke cost scales with the number of lines in the draft rather than the total character count.
Profiled locally with performance.mark wrapped around the input handler (Chromium, bun dev web app), typing 51 characters at the end of a draft of the given shape:
Draft shape
DOM nodes
Chars
Median / keystroke
p95
flat single paragraph
1
~20,000
1.0ms
1.5ms
500 lines
~501
~4,000
2.1ms
2.9ms
5,000 lines
~5,001
~44,000
13.8ms
16.4ms
So a long single-paragraph prompt stays fast; a multi-line prompt (pasted logs, code, multi-paragraph instructions) gets progressively laggier the more lines it has, independent of total character count. This looks like the underlying cause behind several existing "typing lag in the chat input" reports (e.g. #36486, #28162, #23330), none of which pin down line count vs. character count as the driver.
Plugins
None
OpenCode version
Reproduced against dev at commit 1882c33 (web app, packages/app + packages/session-ui)
Steps to reproduce
Run the backend (bun run --conditions=browser ./src/index.ts serve --port 4096 from packages/opencode) and the web app (bun dev -- --port 4444 from packages/app), or bun dev web from the repo root.
Start a session with the v2 layout enabled (localStorage.settings.v3.general.newLayoutDesigns = true).
Paste or type a prompt containing a few thousand short lines (e.g. a large log excerpt, one short line at a time).
Keep typing at the end of the draft and compare responsiveness to typing into an empty draft, or into a single flat paragraph of similar total character count.
Screenshot and/or share link
No share link; numbers above come from a local performance.mark/performance.measure profile around the onInput handler in packages/session-ui/src/v2/components/prompt-input/index.tsx, driving keystrokes with document.execCommand("insertText", ...) against the live dev app.
Operating System
Windows 11
Terminal
N/A — reproduced in the web app (Chromium), not the TUI
Activity
github-actions commentedon Oct 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
isturiz commentedon Oct 8, 2026
I have the same issue.
It's especially annoying when I pasted content in the composer.