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
Composer does not grow (or scroll) for Shift+Enter at the end of the draft #5811
In the chat composer, pressing Shift+Enter while the caret is at the very end of the draft inserts the line break (the caret logically moves down) but the input box neither grows nor scrolls to show the new line — the caret falls outside the visible area. Typing any character immediately after "recovers" it: the box grows and the new line appears.
The longer the draft, the more visible this is: once the editor is at its ~10-row cap (220px), the new line is entirely out of view.
Reproduction
Focus the composer, type a few lines (or enough text to reach the height cap — both reproduce it).
With the caret at the very end, press Shift+Enter.
Observe: caret moves to a new line, but the box height/view does not respond.
Type one character: the box suddenly grows and the new line shows.
Shift+Enter mid-draft works fine — the following content already occupies the next line.
Root cause (measured)
Shift+Enter is handled in packages/ui/src/composer.tsx via event.preventDefault() + document.execCommand('insertLineBreak'). In the editor's white-space: pre-wrap context, Chromium's InsertLineBreakCommand at the end of content appends a caret sitter past the inserted break, and that trailing line gets no line box — so the editable's height stays one line short of where the caret sits. When a real character follows, the sitter becomes content, the line gets a box, and the box catches up.
Verified against the editor's exact styles in a minimal repro (pre-wrap, 22px line, 220px max-height, overflow-y: auto):
3 lines, caret at end: offsetHeight 76 → Shift+Enter → 98 (one line short; caret past the box) → type a char → 120.
At the 220px cap, the execCommand path additionally does not scroll (scrollTop stays put), unlike a native keypress which reveals the caret.
The same boxless trailing line can also be produced by a restored draft that ends in \n (e.g. a paste of \"abc\n\" persists through the serializer), where caretToContentEnd parks the caret on it.
Activity
ggbdpq commentedon Oct 22, 2026
take