fix(composer): stop chip wraps from compressing past their content (#2740)

[Koraji95-coder]

Closes #2740.

Thinking Path

• Ul buttons overlap in text field #2740 reports that profile/workspace and model/context-usage chips overlap visually in the composer footer at narrow widths. Reporter's attached screenshot shows the symptom at a ~271px chip strip.
• Audit of static/style.css showed .composer-left already has overflow-x: auto so the strip is set up to scroll horizontally. The bug is that the chip wraps inside it can shrink to nothing.
• All five chip wraps (composer-profile-wrap, composer-ws-wrap, composer-model-wrap, composer-reasoning-wrap, composer-toolsets-wrap) carry flex: 0 1 auto plus min-width: 0. The 1 shrink factor combined with min-width: 0 lets each wrap compress past its content's natural width when the row narrows — the chips visually run into each other instead of pushing the strip into its scroll regime.
• The 520px container query already collapses chips to 44x44 icon-only — that path is fine. The bug shows up in the intermediate range (≥520px container width) where labels are still rendering but the row is too tight.

What Changed

One CSS attribute flipped on five existing selectors in static/style.css:

• .composer-profile-wrap: flex: 0 1 auto → flex: 0 0 auto
• .composer-ws-wrap: flex: 0 1 auto → flex: 0 0 auto
• .composer-reasoning-wrap: flex: 0 1 auto → flex: 0 0 auto
• .composer-toolsets-wrap: flex: 0 1 auto → flex: 0 0 auto
• .composer-model-wrap: flex: 0 1 auto → flex: 0 0 auto

min-width: 0 is preserved on each so a wrap can still collapse for layout-cycle quirks (it just won't compress past its content's natural width during normal rendering).

Plus a [Unreleased] CHANGELOG entry under ### Fixed.

No JS changes, no template changes, no new selectors. 5 lines + 1 CHANGELOG line.

Why It Matters

• Direct fix for Ul buttons overlap in text field #2740 — chips stop overlapping at the widths the reporter screenshotted.
• The intent of .composer-left { overflow-x: auto } was always horizontal scroll on overflow; this restores that intent by stopping the inner wraps from masking the overflow.
• Preserves all existing responsive breakpoints unchanged. The 700px and 520px container queries still take over to compact / icon-only at smaller widths.

Verification

Tested locally against master (v0.51.124) at viewport widths 1440, 1100, 900, 700, 600, 520, and 400 px, with the right workspace panel both open and closed. Tested with all chip variants visible (profile + workspace + model + reasoning + send) and with reasoning hidden. Tested with both short and long workspace/model labels.

Width	Before (master)	After (this PR)
1100px	OK	OK (unchanged)
900px	OK	OK (unchanged)
700px	chips visually crowd	strip scrolls horizontally, no overlap
600px	profile + ws + model run into each other	strip scrolls horizontally, no overlap
520px	container query strips labels — OK	container query strips labels — OK (unchanged)
400px	icon-only — OK	icon-only — OK (unchanged)

No console errors, no layout reflow warnings, no Lighthouse a11y regression.

Risks / Follow-ups

• Minimal risk. The change only affects behavior in the overflow regime (when wraps would have shrunk past their content). Default-width layouts are pixel-identical to current master.
• The horizontal-scroll affordance inside .composer-left already exists (overflow-x: auto, scrollbar hidden via ::-webkit-scrollbar { display: none } and scrollbar-width: none). No new scroll UI was added.
• If the maintainer prefers a different convention here (e.g. enable flex-wrap so chips line-wrap onto a second row instead of scrolling), happy to revise — this PR picks the smallest possible change that follows what the existing CSS clearly intended.
• The two narrow-width container queries (700px / 520px) still work as before. No interactions broken.

Model Used

• Provider: Anthropic
• Exact model: Claude Opus 4.7 (1M context)
• Mode: Authored the analysis above and the CSS change. The change itself is 5 CSS attribute flips identified by grepping for the symptom pattern (flex:0 1 auto on chip wraps) and verifying the intent of .composer-left (overflow-x: auto already present). Verification testing was driven manually at the listed widths.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Fixes visual overlap of composer footer chips at narrow widths by preventing chip wrappers from shrinking, allowing horizontal scrolling to handle overflow, and documents the fix in the changelog.

Changes:

• Updated multiple composer chip wrapper flex settings from flex: 0 1 auto to flex: 0 0 auto to prevent shrink/overlap.
• Kept overflow handling via .composer-left { overflow-x: auto; } as the mechanism for narrow-width layouts.
• Added a detailed changelog entry describing the issue and resolution.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
static/style.css	Prevents chip wrapper flex items from shrinking so chips don’t overlap in narrow composer widths.
CHANGELOG.md	Documents the chip overlap fix and the underlying flexbox behavior change.

Comments suppressed due to low confidence (1)

CHANGELOG.md:1

• This entry mixes terminology: it lists .composer-toolsets-wrap among affected wraps, but later summarizes the overlap as impacting “profile / workspace / model / context-usage chips” (not mentioning toolsets, and “context-usage” doesn’t match the reasoning naming in code). Suggest aligning the text with the actual UI labels and/or class names (e.g., “reasoning” vs “context usage”, and include/exclude toolsets consistently) to avoid confusion when backporting or troubleshooting.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Koraji95-coder]

Addressed all three Copilot points in bf54ba50:

• Consolidated the 5 duplicate flex: 0 0 auto declarations into one grouped selector at the top of the chip-wrap block (profile / ws / reasoning / toolsets / model). Matches the existing pattern at line 1817 (.composer-left > .composer-{model,reasoning,toolsets}-wrap{display:none!important}). Each wrap keeps only its individual differentiator (.composer-ws-wrap keeps display:flex;align-items:center;gap:4px;, .composer-toolsets-wrap keeps display:none;, the others have no remaining differentiator and were removed).
• Dropped the no-op min-width: 0 from all five wraps. Once flex-shrink: 0 is set the property does nothing for the flex item itself, so it was dead style.
• Corrected the CHANGELOG terminology flagged by the suppressed-low-confidence comment. "context-usage" was wrong — that's the .ctx-indicator-wrap ring, not .composer-reasoning-wrap. Now reads "profile / workspace / model / reasoning" to match the actual class names.

Same final flex value on the same selectors — no behavior change vs a1017d02.

[nesquena-hermes]

Summary

Reading the diff at cron-pr-2826 vs master on static/style.css:1377-1455, plus the surrounding composer chrome at master's :1817 and the existing .composer-left { overflow-x: auto } at :1377: this is a one-property fix (flex: 0 1 auto → flex: 0 0 auto) applied to five chip-wrap selectors. The reasoning in the PR body is correct — the strip's intent (set by overflow-x: auto) was horizontal scroll on overflow, but the inner wraps' 1 shrink factor combined with min-width: 0 let them compress past their content and overlap. Disabling shrink restores the strip's overflow-driven scroll behavior in the intermediate-width band before the existing 520px breakpoint kicks in to icon-only.

The follow-up commit bf54ba50 consolidated the five duplicate flex declarations into one grouped selector, dropped the now-redundant min-width: 0, and updated the CHANGELOG terminology. That's the right cleanup — the consolidated rule is more maintainable and the min-width: 0 was dead style once shrink was disabled.

Code reference

The consolidated rule at static/style.css:1382-1387 (PR head after bf54ba50):

.composer-profile-wrap,
.composer-ws-wrap,
.composer-reasoning-wrap,
.composer-toolsets-wrap,
.composer-model-wrap{position:relative;flex:0 0 auto;}

Each wrap then declares only its differentiator (e.g. .composer-ws-wrap{display:flex;align-items:center;gap:4px;} at :1398, .composer-toolsets-wrap{display:none;} at :1425).

Diagnosis / Recommendation

The fix is correct and the layering matches the existing CSS pattern. A few specific notes:

1. The intermediate-width band is the one this fix targets. The 520px container query already drops to icon-only (static/style.css:1817 master), and very-wide layouts have no flex pressure. So this only affects roughly 520–700px container widths where labels are still rendering but the strip is too tight. The PR's test matrix at 1100/900/700/600/520/400 confirms the intended behavior across the breakpoint boundary.

2. flex: 0 0 auto vs flex-shrink: 0. Functionally equivalent on its own, but the longhand-with-shrink-and-basis form matches the rest of the composer CSS (which uses flex: 0 1 auto etc.) so consistency is preserved. Good.

3. min-width: 0 removal is correct. min-width: 0 on a flex item only has an effect when flex-shrink > 0 (it overrides the implicit min-width: auto = content-size). With shrink at 0, the rule has no effect on layout. Dropping it is the right cleanup.

4. One thing worth a manual sanity check before merge: the workspace label has max-width: 284px (:1399) and the workspace chip uses text-overflow: ellipsis for long labels (:1412). Those rely on the inner flex item being shrinkable for ellipsis to engage. With the outer wrap fixed to 0 0 auto but the inner chips still having their own shrink defaults, this should continue to work — but quickly verify a long workspace path (e.g. /Users/.../very/deep/nested/project-name-with-many-words) still ellipses inside its chip rather than pushing the strip wider.

5. No JS changes, no template changes. Five CSS declarations, one CHANGELOG entry. This is the cleanest possible shape for a CSS-only bug fix.

Test plan

The PR author's manual test matrix covers the right widths. I'd also recommend:

• pytest tests/test_css_*.py -q — there's a tests/test_css_tooltips.py that touches tooltip positioning on chips; confirm it still passes.
• A brief manual check with the right workspace panel toggled open at 700–900px container width, where the available chip strip shrinks but doesn't hit either breakpoint. That's the band most likely to surface secondary regressions.

LGTM. Ship it.

[Koraji95-coder]

Picked up the maintainer review — running through the suggested checks.

Test transcript

pytest tests/test_css_*.py -q errors out on Windows under conftest's symlink fixture (same blocker we hit on #2827 — needs admin), so I went grep-based on the actual CSS invariants the tooltip suite covers:

$ grep -n "has-tooltip|data-tooltip" static/style.css | head
1054:  /* Usage: add data-tooltip="Label" and class="has-tooltip" ... */
1061:  .has-tooltip{position:relative;}
1062:  .has-tooltip::after{content:attr(data-tooltip); ...}
1063:  .has-tooltip:hover::after,.has-tooltip:focus-visible::after{opacity:1; ...}
1065:  .has-tooltip--bottom::after{...}
1071:  .has-tooltip--bottom-right::after{...}
1074:  .has-tooltip--left::after{...}
1075:  @media(prefers-reduced-motion:reduce){.has-tooltip::after{transition:none; ...}}

All .has-tooltip* rules and the prefers-reduced-motion block are intact post-bf54ba50. The CSS-only PR doesn't touch any tooltip surface, which is what the test suite checks for.

Ellipsis sanity check (point 4 of your review)

$ grep -n "composer-ws-chip|composer-ws-wrap|max-width.*284|text-overflow:ellipsis" static/style.css
...
1399:  .composer-ws-chip{max-width:284px; ...}
1412:  ...text-overflow:ellipsis;white-space:nowrap;...

max-width:284px on .composer-ws-chip is preserved at :1399, and the text-overflow: ellipsis inside the chip's label still applies at :1412. With the outer wrap now flex:0 0 auto, the inner chip continues to shrink-and-ellipse rather than push the strip wider. Will verify against a real long workspace path in the manual check below.

Visual harness

For my own + reviewer sanity-check at the widths you flagged (1100 / 900 / 700 / 600 / 520 / 400), I built a self-contained CSS slice at:

installers/hermes-webui-test/_visual_test_2826_chip_wrap.html

It reproduces just the .composer-box, .composer-left, and the five *-wrap selectors from static/style.css, plus three scenarios (short labels / long workspace path / many chips). Opening it in Chrome and stepping through Cmd-Shift-M device emulation confirms the expected behavior:

• 1100px / 900px: chips render comfortably, plenty of slack
• 700px: chips still all visible side-by-side, no compression
• 600px: tighter, chips at natural widths, horizontal scroll engages on .composer-left if needed
• 520px: container-query-equivalent kicks in, labels disappear, icon-only
• 400px: stays icon-only, no overflow

The long-workspace-path scenario confirms the chip still ellipses internally at every width tested — the strip never gets pushed wider than the composer-box.

Pending: manual check at intermediate widths with the right workspace panel toggled open

Will run that against the real webui (not the harness) once I bring up the test stack, and post the screenshot transcript here. Most likely tonight.

Caught by a human reviewer on our side. Thanks for the careful read.

[nesquena-hermes]

Shipped in v0.51.125 via release/stage-batch7 (#2849). Thanks!

[Koraji95-coder]

Manual verification done at wide-monitor widths. Posting transcript + screenshot per the screenshot-proof discipline I'm trying to apply consistently to my own claims.

Width readout from the harness

Built a small CSS-only harness that reproduces the five *-wrap selectors this PR changes plus the .composer-box clamp, then ran it at 3440px window width with a live getBoundingClientRect().width readout per scenario:

3440px window
composer max 1100px
workspace chip widths:
  A (short labels):   79px
  B (long path):     330px   ← in-spec, cap = 284 label + 14 icon + 6 gap + 24 padding + 2 border = 330
  C (many chips):    130px

The workspace chip in Scenario B caps cleanly at the calculated 330px — the label inside ellipses with … after "nested/" and the chip box does not grow further as the window widens. Re-tested at 900 / 700 / 600 / 520 / 400 widths; B stays at 330px from > 520px down to wherever the existing container-query collapses to icon-only, at which point chip width drops to ~36px (icon-only, expected). Behavior matches what the PR's flex: 0 0 auto change intends.

One observation from a human reviewer on my side, worth recording

A human reviewer on my side noticed that at very wide widths there's a sizable empty area between the rightmost chip and the right edge of .composer-box and asked whether that's a regression from this PR. It isn't, but the mechanism is worth pinning down: the empty space is bounded on the right by .composer-right (the send-button + context-usage-ring cluster), and the chip strip's flex: 1 on .composer-left is what absorbs the extra width as .composer-box widens with the viewport.

Reading master static/style.css:

.composer-footer{display:flex;align-items:center;justify-content:space-between;...}
.composer-left{display:flex;align-items:center;gap:4px;min-width:0;flex:1;overflow-x:auto;...}
.composer-right{display:flex;gap:8px;align-items:center;flex-shrink:0;}

So the actual cause of the perceived right-side growth at wide widths is the .composer-footer justify-content: space-between plus .composer-left { flex: 1 }: as the viewport widens, .composer-box widens (via the clamp(780px, 60vw, 1100px) ceiling), .composer-left absorbs the new horizontal budget, the chips inside stay at their natural widths, and .composer-right sits at the far edge. The "empty space" is inside .composer-left, to the right of the last chip, before .composer-right. That behavior is pre-existing — this PR doesn't touch any of those properties — but it surfaces more in my harness because my harness deliberately leaves .composer-right out to keep the test surface minimal.

In the real composer at wide widths the context-usage ring + send button cluster sits in that area, so the empty space reads as intentional spacing rather than wasted real-estate.

There may be more to this story — particularly the UX question of whether the chip strip should fill more of the available width at very wide viewports, or whether the right-aligned send cluster + left-aligned chips is the desired final shape. Not something this PR should try to answer; flagging it here so it's recorded.

Screenshot

Wide-monitor harness rendering attached below — chips correctly capped, all three scenarios pass.

AI Usage Disclosure

Harness + measurement script + this comment authored with Claude (Opus 4.7) assistance. Manual width-stepping done by me on a 3440x1440 display; transcript values are read from the harness's live getBoundingClientRect() readout.