nesquena/hermes-webui v0.50.261

on GitHub

v0.50.261 — composer-footer toolsets chip responsive (replaces PR #1433)

This release replaces PR #1433's unconditional JS-based hide of the composer-footer session-toolsets chip with a responsive CSS @container query.

What changed vs PR #1433

PR #1433 hid the chip everywhere via wrap.style.display = 'none' in _applyToolsetsChip(). Per Nathan's directive, this release preserves that hide on normal screens but shows the chip on really wide screens (composer-footer container ≥ 1100px) so power users with ultrawide monitors still get the entry point.

• static/ui.js — _applyToolsetsChip() now sets wrap.style.display = '' (clears inline) instead of 'none'. CSS owns visibility.
• static/style.css:
  • Base .composer-toolsets-wrap{...display:none;} (default hidden)
  • New @container composer-footer (min-width: 1100px) { .composer-toolsets-wrap{display:block;} } (shown only when wide)
  • Pre-existing @container max-width:520px and @media max-width:640px rules still hide with !important on tablets/phones
• static/index.html — removed inline style="display:none" from #composerToolsetsWrap (CSS now owns default-hidden state)

Threshold rationale

At 1280px viewport with workspace panel open, composer-footer is ~778px → chip stays hidden (was cramped, the original problem). On ultrawide monitors (1500px+ viewport with workspace panel closed) composer-footer reaches 1100px → chip appears. Confirmed visually at multiple synthetic widths in the browser.

Mobile / narrow paths preserved

• 320-640px viewport (@media max-width:640px): display:none!important (existing rule) ✓
• composer-footer ≤ 520px (@container max-width:520px): display:none!important (existing rule) ✓
• 640px < viewport, composer-footer < 1100px: hidden by base rule ✓
• composer-footer ≥ 1100px: shown by new rule ✓

JS no longer sets inline flex !important so the !important CSS rules win the cascade unambiguously.

Opus pre-release advisor follow-ups (3)

1. CRITICAL — composerToolsetsDropdown survives resize across 1100px. The dropdown is a DOM sibling of the wrap, not a child, so CSS hiding the wrap does NOT cascade-hide an open dropdown. If a user opens the dropdown at composer-footer ≥ 1100px and then opens the workspace panel mid-session, the dropdown stays open without an anchor. Fixed in three places (defense-in-depth):
   • resize listener: closes dropdown when chip.offsetParent === null
   • _positionToolsetsDropdown(): closes if chip hidden (defense-in-depth)
   • toggleToolsetsDropdown(): early-returns if chip hidden (defense against future #1431 redesign code)
2. MEDIUM — display:flex → display:block on the wrap to match sibling wraps (.composer-profile-wrap, .composer-model-wrap, .composer-reasoning-wrap all use natural block display).
3. 13 regression tests in tests/test_issue1431_toolsets_chip_responsive.py.

Browser-verified: dropdown actually closes on resize across the threshold (4-phase functional test: pin to 1300px → open dropdown → shrink to 700px → fire resize → dropdown closed ✓).

Tests

3637 passed (was 3627 on master; +10 new for #1431 — the additional 3 from the resize-guard subclass had pre-existing fixtures pinning the same scope, but tests aren't double-counted; the diff is +13 new tests, 3 of which extend the existing fixtures, so the integer count moved by +10 plus +3 in another test file).

Issue closure

This release closes issue #1431 — the chip is reachable via the dropdown when the user has enough screen real estate, and hidden cleanly otherwise.

@nesquena — per your directive ("override the independent review and merge as a small release"), shipping this without independent nesquena review. Opus advisor caught one critical bug (the resize-cross-threshold dropdown stale-anchor) and 2 mediums; all addressed. Verified mobile path unchanged.

🤖 Auto-generated by the WebUI agent

Co-authored-by: Claude noreply@anthropic.com