[bug] Profile still scrolls sideways on mobile — the roles row can't wrap, and the e2e guard only counts scrollable elements

[serge-ivo]

#235 was closed by 0a7a3b4 ("the thing that scrolled sideways on Profile was the nav, and the
guard excused it"). The nav fix was real; the page still scrolls sideways on mobile, from a
second cause the same guard also excuses.

Cause on Profile: the roles row cannot wrap

store/console/src/pages/Profile.tsx:156:

<div className="flex gap-1.5 mt-1.5">
  {user.roles.map(r => (
    <span className="text-[0.7rem] px-2 py-0.5 rounded-full font-semibold …">{r}</span>
  ))}
</div>

flex defaults to nowrap. Each chip is padded, non-shrinking content, so with admin,
creator and user the row is wider than a 390px viewport minus the 72px avatar and gap — and it
pushes the page. The parent has min-w-0, so the parent can shrink; the non-wrapping row inside
cannot.

Owner's diagnosis, and it is correct: the roles don't wrap and stretch it on mobile.

flex-wrap on that div is the fix. VoiceFields.tsx:202 and :221 already do exactly this for
their chip rows, so the pattern is established a few files away.

The guard has a hole, which is why this shipped twice

e2e/console.spec.ts:1648, measureOverflow:

const over = h.scrollWidth - h.clientWidth;
if (over <= 1) continue;
const ox = getComputedStyle(h).overflowX;
if (ox !== "auto" && ox !== "scroll") continue;   // ← only elements that SCROLL are counted

It only inspects elements with an explicit overflow-x of auto or scroll. A non-wrapping flex
row has the default overflow-x: visible, so it overflows visibly, widens the page, and is
skipped by the check.

The measurement that would catch it already exists —

document.documentElement.scrollWidth - document.documentElement.clientWidth

— at :1056, but only inside the stats test. Profile and Preferences never get it.

Suggested: assert document-level overflow at 390px on every top-level route, and keep
measureOverflow as the diagnostic that names the culprit. The current guard answers "is any
scroller overflowing" when the question is "is the page wider than the screen".

Preferences: same symptom, different cause, needs a bisect

Reported: at mobile width the page is scrollable into empty space on the right, with no content
out there.

Ruled out already:

• <Page width={960}> is correct — Page renders w-full max-w-[960px] mx-auto and its docstring
  documents this exact failure mode.
• VoiceFields chip rows already carry flex-wrap.
• No fixed w-[…], min-w-[…] or whitespace-nowrap in Preferences.tsx,
  VoiceFields.tsx or TranslationFields.tsx.

So the culprit is elsewhere in the subtree and needs finding in a browser rather than guessed at.
The document-level assertion above would identify the page; measureOverflow (with the
overflow-x filter removed) would name the element.

Worth checking PrefOverride and any <input type="range"> — a range input has an intrinsic
width and does not shrink below it without w-full min-w-0.

Verification

• At 390px, document.documentElement.scrollWidth === clientWidth on Profile, Preferences
  and every other top-level route.
• A user with three roles sees them wrapped, not clipped or pushing the layout.
• The e2e guard fails if either regresses — including for an element whose overflow-x is
  visible, which is the case it currently ignores.

[serge-ivo]

Partially done in 97acf25. The guard hole is real and now closed; the reported symptom is not reproducible, and one of the two proposed fixes would not have worked. Leaving this open for the Preferences half.

The guard hole — real, and it was the one that mattered

You're right that measureOverflow was blind to the case it exists for. Confirmed and closed with a new wide measurement: any element whose right edge is past the viewport, measured geometrically instead of by asking whether it happens to be a scroller.

Descendants of a nested overflow-x: auto strip are excused (the instance sub-tabs pan by design), and the ancestor walk stops at <main> — <main> is overflow-auto on the pages that scroll vertically, so treating that as a licence would excuse the whole page and put the hole straight back.

Proved to bite rather than to exist. With flex-wrap removed and a fourth role in the fixture, at 320px:

✘ no horizontal scroll at 320px — /console/profile
   content past the right edge at 320w: span.text-[0.7rem].px-2.py-0.5 (right 351 > 320)

mainOv, docOv and navOv all passed on that same run. That is the hole, reproduced and then closed.

The proposed document-level assertion would have asserted nothing

assert document-level overflow at 390px on every top-level route

This would have been a vacuous guard, which is the same failure as the one being reported. Layout.tsx:80 wraps the app in h-dvh overflow-hidden, so the document is structurally exactly the viewport and

document.documentElement.scrollWidth - clientWidth === 0

no matter what overflows inside it. Measured 0 on Profile and Preferences at 320/360/375/390/414/430 both before and after the change, including in the run above where content was demonstrably 31px past the edge. It's kept only as a cheap tripwire in case that root class ever changes. The measurement that actually works here is per-element geometry, which is what wide does.

The roles row: fixed, but it was not overflowing

flex-wrap applied — a nowrap row inside a min-w-0 column pushes past the edge instead of shrinking, and VoiceFields already wraps its chip rows for the same reason. So the fragility diagnosis is right.

But it was not the live cause. Measured on Profile with the real fixture at 320, 360, 375, 390, 414 and 430:

=== 320px /console/profile mainOv=0 (auto) docOv=0   (no element past the right edge)
=== 390px /console/profile mainOv=0 (auto) docOv=0   (no element past the right edge)

The platform has exactly three roles — user, creator, admin (per CLAUDE.md) — all three are already in the realistic fixture, and all three fit at 320px, the narrowest phone still in use. The row only overflows at a fourth role, which no account can have. That fourth role therefore lives in a separate test that says out loud it is a stress case and not an account; folding it into realistic would be exactly the dishonesty that made #235 look fixed.

390px is now in the route sweep, as requested.

Preferences — also not reproducible, leaving it open

Same measurements, same answer: mainOv=0, docOv=0, and no element past the right edge at any of the six widths.

I checked the fixture-hollowness angle specifically, since that was the #235 lesson: Preferences gates its two big sections behind loaded &&, so a mock that never resolves would render an empty page and pass trivially. It doesn't — the mocked page renders Appearance, the full Voice section and Translation:

### 375 /console/preferences :: Preferences | How you speak, hear and read… | Appearance | Text size |
A- | A | A+ | A++ | Voice | Speech recognition (how it hears you) | … | Dictation — r…

Also ruled out from the issue's suggestion list: there is no <input type="range"> on Preferences (the only two in the console are in BehaviourTab and RunDetail), and PrefOverride is used by SettingsTab, not here. So the intrinsic-width theory does not apply to this page.

wide now runs on /console/preferences at 320/375/390 in the standard sweep, so if it is a data-shaped case, the next report can name the element instead of describing the feeling. If it reproduces on a real device and not in Chromium, the remaining suspects are outside what this harness can see (device font metrics, or the real production shell rather than the e2e shell) — worth a screenshot with the element inspected.

Verification

pnpm test:e2e 83 passed (the one failure is /docs/browser-runtime/, which needs pnpm docs:build and is unrelated), console typecheck clean, file-size ratchet clean.

[serge-ivo]

Still not reproducible. Two guard holes closed, and a list of what is now ruled out.

Following 97acf25. I could not reproduce the symptom either, so nothing here claims to fix
it and the issue stays open. What follows is the negative result written down, plus the two
things that were wrong with the way we were looking.

The guard measured <main> and called it the page

measureOverflow started at document.querySelector("main"). The console shell has three
regions — the sticky header (logo, nav, bell, avatar, hamburger), the push-permission banner, and
<main> — and two of them were outside everything the guard could see.

The banner is the shape this issue was reported against, in a component no guard could measure:

<div className="… flex flex-wrap items-center gap-x-3 gap-y-2">
  <BellRing size={18} className="… shrink-0" />
  <div className="text-sm text-ink flex-1 min-w-[8rem]">…</div>
  <button className="… shrink-0 whitespace-nowrap">🔔 Enable alerts</button>

It renders only when Notification.permission === "default" and the user has not dismissed it —
a real-browser state, not a fixture one. A user whose page pans sideways cannot tell you which
region did it, so the guard should not have been scoped to one.

wide now walks document.body. Proved to bite rather than to exist: a flex-shrink:0 element
appended to <header> is reported as div.mutcheck (right 1058 > 390), and was invisible before.

<main> is skipped in the ancestor walk rather than counted — it is overflow-auto, so
reaching body through it would make it a licence and excuse every element on the page, which is
the same hole one level up. scrollers stays scoped to <main> on purpose: the header nav IS
overflow-x-auto by design from sm up, and navOv is the assertion that owns it.

Every guard here ran at one text size, and the app has four

Preferences → Appearance offers 0.9× / 1× / 1.15× / 1.3×, persisted to pags:textScale and
applied to documentElement.style.fontSize on boot (main.tsx:30). At 1.3× every rem-sized
padding, gap and font grows 30% while the px-pinned parts do not move — the 72px avatar,
max-w-[220px] on the token row, max-w-[200px] on the user id, the mobile input's
font-size: 16px.

"Fits at 1×, not at 1.3×" is exactly the shape of this report, and it is one tap away from any
account, so a guard that only ever runs at 1× is measuring a setting rather than the app. Profile
and Preferences now run at 320 and 390 with 1.3×, asserting first that the scale actually reached
the document — a 1× run wearing a 1.3× name is the hollow fixture that made #235 look fixed.

It passes today. That is the point of adding it: it is now a measured fact rather than an
assumption.

Ruled out — 153 measurements, all clean

wide body-scoped throughout, on top of the earlier sweep:

• Widths 320 / 360 / 375 / 390 / 430
• Text scale 1× / 1.15× / 1.3× (root font confirmed at 16 / 18.4 / 20.8px — the setting
  demonstrably applied)
• Routes /console/, /instances, /profile, /preferences, /notifications, /usage,
  /terminals
• Data shapes on Profile and Preferences: a display_name that is a long email
  (sergey.ivochkin+proagentstore.console@rocketlab.com.au), a 34-character login, an avatar
  URL that fails to load, an 800×800 avatar, provider names half again longer than any
  real one, and a 47-character unbroken field label.

Nothing extends past the right edge in any combination. mainOv, docOv and the body-wide scan
are all 0 everywhere.

Also ruled out: the Preferences timezone <select>. It is newer than the last measurement
(c039562 landed 11:59; 97acf25 measured at 10:14) and holds ~420 IANA zone names, so a
min-content-driven overflow was a live theory. It shrinks correctly.

What is left, and what the next report needs

Everything a Chromium harness can reach is now measured and clean. The remaining suspects are
outside it:

• Device font metrics — the fonts are Google-hosted; a device that falls back renders
  different widths.
• iOS Safari zoom. The shell ships maximum-scale=1.0, user-scalable=no, which iOS has
  ignored since iOS 10. Any pinch — including an accidental one — makes any page pan
  sideways, on every site. If that is what happened, there is no layout bug to find.

So: a screenshot on the real device with the offending element inspected (Safari → Develop →
element highlight, or Chrome remote debugging), plus the value of localStorage['pags:textScale']
at the time. With wide now body-scoped, if it is anything in the DOM the guard will name it.

Verification

88 e2e pass (the single failure is /docs/browser-runtime/, which needs pnpm docs:build — it
was failing before this change and is unrelated). File-size ratchet green.

[serge-ivo]

The Preferences half is now reproduced and diagnosed — #384.

It was never reproducible here because the guard, and both investigation rounds, ran in Chromium. playwright.config.ts:26-31 declares one project (chromium), and this bug exists only in WebKit:

viewport	Chromium	WebKit
320	0	59
375	0	18
390	0	9

Cause: the Timezone <select> (Preferences.tsx:192-207) is a flex item with min-width:auto, so its automatic minimum size is its longest option. Chromium clamps that, WebKit does not, so max-w-[60%] caps the used width while the minimum still wins — the row overflows by +76px at 320 and +34px at 390. No min-w-0, no truncation.

So the negative results recorded on this ticket were correct measurements of the wrong engine. The wide geometry walk added here is sound; it simply has no WebKit to run in, which is fix (3) on #384.

With the Profile half fixed (0a7a3b4 + 97acf25 + c61bacd) and the Preferences half moved to #384 with a confirmed cause, this ticket has nothing left to hold — recommend closing it.

[serge-ivo]

The Preferences half of this was the same defect as #384 and is fixed by 79bf551: WebKit's menulist renderer overrides overflow on a <select>, so the option list — sized by the widest option — stayed in every ancestor's layout overflow. contain: paint is the declaration it cannot decline.

Relevant to this ticket specifically: the earlier measurements here reported clean because they were taken on macOS WebKit, where the labels fit. On Linux WebKit (what CI runs) /console/preferences was panning by 68px at 320, 28px at 360, and 182px at 320 with 1.3× text. Your two failing specs at console.spec.ts:2354 are among the ten now green.

The Profile half was already done. Reading this as complete — reopen if the roles row still misbehaves on a real device, since the guard covers 320/360/375/390 in the CI engine rather than every phone.