Mobile: per-host status line forces horizontal page scroll at 320px #42

New Issue

clawbot · 2026-08-09T16:50:20+02:00

clawbot commented

2026-08-09 16:50:20 +02:00

Found by the responsive-layout harness added for #13
(make frontend-viewport-test). This is a real defect in the layout, not a
harness artifact.

Symptom

At a 320px viewport the page scrolls horizontally: documentElement.scrollWidth
is 350 against a 320px layout viewport. Reproduced at every run, only at 320px —
667, 767, 768, 769, 844 and 1280 are clean.

Cause

.status-text in hostRowHTML() (src/main.js) carries whitespace-nowrap,
and once a tick has populated it the content reads e.g.
min 167ms / med 167ms / avg 167ms / max 167ms. Measured at 320px that is 325px
of unbreakable text inside a 270px box, and since the element does not clip, the
overflow propagates all the way up to the document:

div.status-text.text-xs | rect 25..295 w270 | scrollWidth 325 / clientWidth 270
                        | overflow-x: visible  white-space: nowrap

The max-width: 768px block in src/styles.css sets the info block to
width: 100% but never addresses this line, so the narrow layout inherits a
nowrap string sized for the 420px desktop column.

Suggested fix

Allow the status line to wrap (or shorten it) below the breakpoint. Any fix is
fine as long as make frontend-viewport-test reports no-horizontal-overflow
passing at 320x568 — the harness already asserts this and names the offending
element on failure.

Note for whoever picks this up

window.innerWidth is useless for detecting this. Under mobile emulation Chrome
lets innerWidth grow to the width of the overflowing content — it reports 350,
matching the overflow exactly, so a check written as
scrollWidth <= innerWidth passes while the page is visibly broken. The
harness compares against Math.min(innerWidth, documentElement.clientWidth)
instead.

Ref #13, #5, #2

Found by the responsive-layout harness added for #13 (`make frontend-viewport-test`). This is a real defect in the layout, not a harness artifact. ## Symptom At a 320px viewport the page scrolls horizontally: `documentElement.scrollWidth` is 350 against a 320px layout viewport. Reproduced at every run, only at 320px — 667, 767, 768, 769, 844 and 1280 are clean. ## Cause `.status-text` in `hostRowHTML()` (`src/main.js`) carries `whitespace-nowrap`, and once a tick has populated it the content reads e.g. `min 167ms / med 167ms / avg 167ms / max 167ms`. Measured at 320px that is 325px of unbreakable text inside a 270px box, and since the element does not clip, the overflow propagates all the way up to the document: ``` div.status-text.text-xs | rect 25..295 w270 | scrollWidth 325 / clientWidth 270 | overflow-x: visible white-space: nowrap ``` The `max-width: 768px` block in `src/styles.css` sets the info block to `width: 100%` but never addresses this line, so the narrow layout inherits a nowrap string sized for the 420px desktop column. ## Suggested fix Allow the status line to wrap (or shorten it) below the breakpoint. Any fix is fine as long as `make frontend-viewport-test` reports `no-horizontal-overflow` passing at 320x568 — the harness already asserts this and names the offending element on failure. ## Note for whoever picks this up `window.innerWidth` is useless for detecting this. Under mobile emulation Chrome lets `innerWidth` grow to the width of the overflowing content — it reports 350, matching the overflow exactly, so a check written as `scrollWidth <= innerWidth` passes while the page is visibly broken. The harness compares against `Math.min(innerWidth, documentElement.clientWidth)` instead. Ref #13, #5, #2

clawbot referenced this issue from a commit