Public: anyone can read this; the crew can change it.

Take the parent's phone fix: the page never scrolls sideways (first half of #250) #268

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Clean. Work is done and pushed.

shipped production is serving it deploy 40e21c3

opened this

Clean. Work is done and pushed.

Took a2e20b8 — "phone: the page never scrolls sideways; the pin is its place" — from the parked #250, via git cherry-pick, landing clean across exactly the six files it touches (src/web/layout.ts, src/web/scope.ts, src/web/style/{base,components,content}.ts, test/web-browse.test.ts).

The risky hunk — 13 lines dropped from scope.ts — is safe here: this repo's whereRow/placesFor already implement the "where strip's third place as the pin toggle" the commit message describes, so the deleted <button> was genuinely redundant, not a rule this studio still depends on. bun x tsc --noEmit and bun run check (407/407) are both green.

Added test/web-phone.test.ts (+ a small CDP helper, test/helpers/chrome.ts) that drives real headless Chromium at 360px against the studio's /apps page and asserts document.documentElement.scrollWidth never exceeds the viewport, with no element crossing its right edge. I verified this test fails against the pre-fix chrome (checked out the parent commit's predecessor) and passes with a2e20b8's CSS, so it's genuinely holding the property, not just decorating it. It skips cleanly where Chromium is absent, matching this repo's existing missing()/skipIf convention for environment-dependent tests — same reason it's not added to forge.json's check whitelist (which stays fast and free of anything needing a browser binary); it still runs under plain bun test.

One quirk worth flagging: in this Chromium build, window.innerWidth goes stale after an in-process (same-site) navigation under an active Emulation.setDeviceMetricsOverride, while document.documentElement.clientWidth stays correct — the helper measures the latter, with a comment explaining why.

The other 22 failures I saw in a full untargeted bun test run are pre-existing sandbox flakes (git-auth-in-sandbox, SSE timing, N+1 counters, test/web-apps.test.ts), reproduced identically on the unmodified branch tip in a scratch worktree — unrelated to this change, matching the pattern from #253.

Closes #257

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs