fix(webapp): the page no longer glides under a phone tap (J5's lost taps, #875) #882
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/j5-phone-flake"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #875.
The cause
.book__main, the app's scroll container, hadscroll-behavior: smooth. That animated every scroll of the page, including:On a phone, Chrome builds the click from the tap after
touchendand hit-tests it at that moment. If the page is still gliding, the click lands on whatever slid under the finger. So Strike didn't strike and Reword didn't open.On desktop the click goes out with the mouse-up, before the first animation frame, which is why only the phone project failed.
Evidence comes from traces plus a scroll and input event log, recorded with local-only instrumentation:
:105("Accurate") follows from the first failure. It only failed on a retry. A retry re-runs the serial block with Priya's answer already saved, and pressing it again takes the answer back by design. So once:213fails, a failing:105retry is guaranteed; it isn't a second bug.Honest limit: we never reproduced a red run locally, even under stress and with CPU throttling. The mechanism comes from traces and the event log. The margin was about 15 ms locally, which is thin enough that CI's loaded runners would lose some taps.
The fix
AppShell.css: removedscroll-behavior: smoothand its reduced-motion override, with a comment saying why.ui/motion.js, exported from the kit:jumpTo(el)glides for a jump the reader asked for, or jumps at once underprefers-reduced-motion. It's used for:Tests
ui/motion.test.js:src/setsscroll-behavior: smooth. It fails against main'sAppShell.css.jumpTocases.changelog.d/fragment.🤖 Generated with Claude Code