Skip to content

v2 prompt composer: typing slows down proportionally to the number of lines in the draft #40225

Closed as not planned

Description

@ayouboa30

Description

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

  1. 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.
  2. Start a session with the v2 layout enabled (localStorage.settings.v3.general.newLayoutDesigns = true).
  3. Paste or type a prompt containing a few thousand short lines (e.g. a large log excerpt, one short line at a time).
  4. 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

  1. github-actions commented on Oct 3, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  2. isturiz commented on Oct 8, 2026

    @isturiz

    I have the same issue.

    It's especially annoying when I pasted content in the composer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions