Repository navigation
fix(MobileNav): the drawer is never wider than 85% of the viewport - #8063
Conversation
The width prop is documented as "capped at 85vw to prevent overflow on small screens", but the drawer's width was min(100vw, width): on a 320 px phone the default 320 px drawer covered the whole screen and left no backdrop to tap. It is now min(width, 85vw), so a 48 px strip of the page stays beside it, and a tap there closes it. Wider screens are unchanged.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
the
needs:design-review
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewNo new or modified components detected. Bundle Size Summary
Accessibility AuditStatus: No accessibility violations detected. Visual Regression46 of 494 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 26 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
No changes requested: setting the drawer to width: <width>px; max-width: 85vw brings MobileNav back to its documented 85vw cap, so on a 320 px phone the drawer is 272 px wide and a tap on the 48 px backdrop strip beside it closes it, while the default drawer is unchanged from 377 px up. The new jsdom test fails against the current behaviour and the Chromium width contract passes, so the restored cap stays guarded.
[Automated review]
User impact
On a phone narrower than the drawer,
MobileNavcovered the whole screen: the default 320 px drawer on a 320 px phone left no backdrop to tap, although thewidthprop promises "Capped at 85vw to prevent overflow on small screens". The page the drawer navigates was hidden entirely.Problem and solution fit
The drawer's width was
width: 100vw; max-width: <width>px, which is min(100vw, width): the only cap was the viewport itself. A drawer that covers the screen hides its context and takes away the usual way out, a tap beside it; UIKit's overlay sidebar never covers the whole screen. Small phones, zoomed-in text and split-screen windows reach these widths.The fix swaps the two:
width: <width>px; max-width: 85vw, which is min(width, 85vw). On a 320 px phone the drawer is 272 px wide, and a 48 px strip of the dimmed page stays beside it as a target for the tap that closes it.Expected behavior and authority
MobileNav.doc.mjs,width: "Drawer width in pixels. Capped at 85vw to prevent overflow on small screens."Smallest restoration
One style function in
MobileNav.tsx. No API, token or default changes. From 377 px up, 85vw is at least 320 px, so the default drawer is unchanged there.Siblings: #8042, #8046 and #8057 also add
ci.ymlsteps, and #7358, #7356 and the close-path fix #8064 touchMobileNav.tsx; whichever lands second rebases.Evidence
Before (
main) and after, 320 × 568, drawer open:iOS 26.2 simulator, real taps (402 px: the drawer keeps 320 px): a tap on the strip closes it:
mainStorybook (expected 272, received 320).elementFromPointis the dialog), and a real tap on it closes the drawer.MobileNavWidth.a11y.chromium.spec.ts(real Chromium, touch), plus a jsdom test that the drawer's own class declaresmax-width: 85vwand takes its width from the prop.Scope
Testing
pnpm exec vitest run packages/core/src/MobileNav packages/core/src/AppShell: 136 passed.pnpm -F @astryxdesign/core typecheck; eslint and prettier on touched files;pnpm check:repo(pre-commit).pnpm exec playwright test packages/core/src/MobileNav/__tests__/MobileNavWidth.a11y.chromium.spec.ts --project chromiumagainst a fresh Storybook build: 2 passed. Againstmain: the 320 px test fails and the 402 px test passes.