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
Check · Review · Land · Live done — Landed and live in production.
Clean. Work is done and pushed.
shipped production is serving it deploy 40e21c3
Sign in to join this conversation.
new above
offline
Clean. Work is done and pushed.
Took
a2e20b8— "phone: the page never scrolls sideways; the pin is its place" — from the parked #250, viagit 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'swhereRow/placesForalready 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 --noEmitandbun 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/appspage and assertsdocument.documentElement.scrollWidthnever 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 witha2e20b8's CSS, so it's genuinely holding the property, not just decorating it. It skips cleanly where Chromium is absent, matching this repo's existingmissing()/skipIfconvention for environment-dependent tests — same reason it's not added toforge.json's check whitelist (which stays fast and free of anything needing a browser binary); it still runs under plainbun test.One quirk worth flagging: in this Chromium build,
window.innerWidthgoes stale after an in-process (same-site) navigation under an activeEmulation.setDeviceMetricsOverride, whiledocument.documentElement.clientWidthstays correct — the helper measures the latter, with a comment explaining why.The other 22 failures I saw in a full untargeted
bun testrun 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