Sign up
View stargazersSign up

[Bug]: Collapsing the question card still leaves the composer at full height, and scrolling never rests it#14231

openedSep 29, 2026byVVantrongs

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. With Collapse composer on scroll on, get a question from the agent in a thread long enough to scroll.
  2. Collapse the question card with the chevron in its header, to read the thread before answering.
  3. Without typing anything into the answer field, scroll the thread up with the mouse wheel.

Expected behavior

The card collapses "so a tall prompt stops covering the thread the user is trying to read" (comment in ComposerPendingUserInputPanel.tsx). Scrolling should then rest the composer as it does without a question, leaving the card's header row.

Actual behavior

The card shrinks to its header, but the answer field and the footer stay at full height, and scrolling never rests the composer while the question is pending, even when the answer field is empty and I haven't typed anything.

Likely cause

A pending question counts as expanded chrome: showComposerTopDrawer includes pendingUserInputs.length > 0 (ChatComposer.tsx), which sets composerHasExpandedChrome, and canScrollCollapseComposer requires that to be false. Whether the card is collapsed lives in ComposerPendingUserInputPanel (collapsedQuestionId), so ChatComposer never sees it.

Suggested fix

Let a scroll rest the composer when the question card is collapsed, showing the card's header row. To keep a half-written answer safe, decide by focus at the time of the scroll:

  • focus outside the composer (I clicked on the thread) → the scroll rests it;
  • caret in the composer → scrolling the thread, e.g. back through the agent's messages, doesn't rest it;
  • clicking back into the composer expands it with the answer and the selected options intact.

The same rule would also let a multiline draft rest, which #10444 currently prevents; that part is discussed in #6849.

Related

The card's collapse toggle came in #6773; the wider idea of getting the composer out of the way while a question is pending is #6849.

Impact

Minor bug or occasional failure

Version or commit

0.0.43-nightly.20260928.2375; code references are to main @ d2c9281

Environment

Desktop app on Linux (NixOS, Wayland, niri)

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

None short of answering or dismissing the question.

JJulius MarmingeSep 29, 2026

Triage

Confirmed on current main (d2c9281, the commit this report cites). No later commit changes this path.

The chevron only hides the question body. collapsedQuestionId stays inside ComposerPendingUserInputPanel and toggles that card’s Collapsible. The custom-answer editor and the footer are rendered next to it by ChatComposer, so they stay at full height. That leftover editor is intentional in #6773: a collapsed prompt is still supposed to be answerable.

Scroll-rest cannot finish the job. showComposerTopDrawer is true for any pendingUserInputs.length > 0, and that sets composerHasExpandedChrome. canScrollCollapseComposer requires expanded chrome to be false, and the effect beside it clears isComposerScrollCollapsed whenever the gate is closed. shouldUseRestingComposerLayout also refuses to rest while hasExpandedChrome is true. The collapsed flag never reaches either check, so with Collapse composer on scroll on, an empty collapsed question still cannot rest. Wheel and keyboard timeline scroll share composerScrollCollapseEligibleRef. This is the desktop path; mobile does not scroll-rest.

Not a duplicate:

  • #6773 / #4431 added the header chevron. They do not rest the composer.
  • #10444 keeps a multiline draft expanded. A pending custom answer is not prompt (onPromptChange writes the question draft instead), but useComposerMultilinePrompt still measures the editor, so a wrapped answer is already under that guard. An empty answer is not. Leave multiline drafts in discussion #6849.
  • #6849 is the wider “get the composer out of the way” request (approvals and multiline drafts included). This issue is the pending-question slice already split out there. Approvals use the same expanded-chrome bit and have no chevron; they stay with #6849.
  • #14232 is a different scroll-rest failure: an unmeasured last row makes timelineOverflows false. Unrelated.

The focus rule in the report is not how scroll-rest works today. The wheel handler does not look at editor focus. #10437 removed collapse-on-blur; focus still expands a composer that is already resting. Once the chrome gate allows it, a short custom answer would rest on scroll whether or not the caret is in the field. Keeping an in-progress answer open is worth doing in the fix. It should not also start resting multiline drafts.

JJulius Marminge21d ago

Reproduced in the web dev app on main b5a226e49c, Linux Chromium, 1280×800, DPR 2, with an isolated seeded scrollable thread and pending question. Collapse composer on scroll was enabled. After collapsing the question card, clicking the timeline, and scrolling upward with an empty answer, the answer editor stayed 78 px tall and the footer remained visible.

Recording: collapse at 00:00, scroll at 00:05, click timeline and scroll again at 00:11. Native NixOS/Wayland desktop has not been checked.