fix(widget): stop the chat history list squashing rows instead of scrolling

[vaibhav8a]

Closes #61.

Change

Exactly the fix the issue proposes, in widget/styles/styles.ts:

.thread-drawer-head, .thread-new, .thread-item { flex: 0 0 auto; }

.thread-drawer is a flex column, so those three inherited flex-shrink: 1 and the browser compressed them to fit instead of letting .thread-list overflow and use the overflow-y: auto it already declares.

src/agent_manager/api/static/widget.js is rebuilt with npm run build:widget, since it's committed and carries the bundled CSS — the fix would otherwise not reach anyone serving the prebuilt widget.

Measured

I rebuilt your isolated repro rather than taking the numbers on trust: real Chromium via the repo's Playwright, panel at 440x680, CSS read straight out of styles.ts so the measurement can't drift from what ships.

conversations	row height (before)	row height (after)	scrollable before → after
5	34.2px	34.2px	no → no (correct — nothing to scroll)
20	24.5px	34.2px	no → yes
45	19px	34.2px	yes → yes

That lines up with your table (24.9px / 20px; the ~1px differences are font rendering on this machine). The row height is now constant across 5, 20 and 45 — which is the actual property being fixed: height no longer depends on how many conversations exist.

Checks

npm run build:widget      # bundle rebuilt, carries the rule
npm run typecheck:widget  # clean
npm run test:widget       # widget self-check: OK
pytest tests/api tests/approvals   # 133 passed

The .thread-item ellipsis behaviour is untouched — this only stops the vertical compression, which is the half text-overflow never covered.

[vaibhav8a]

Closing this — #86 has been open since 2 August with the same fix (flex: 0 0 auto on the same three selectors, same rebuilt bundle) and it also carries a Playwright regression test, which mine does not. It should land instead; this is a duplicate and I should have found it before opening.

Apologies for the noise — same miss as #123. I was filtering the issue list on assignee and open-PR branch names, which doesn't catch a PR that references the issue without naming it in the branch. I'm checking closedByPullRequestsReferences on the issue from now on, which surfaces both cases.

@AmitAvital1 no action needed on your side.