A viewport change opens a window in which the feed holds the reader's
video in place, because the scroll-snap container re-anchors on positions
measured against the height from before it and must not be allowed to
flip the video. The window answered every scroll it saw with a realign.
On a phone that is the worst moment to do it: the chrome sliding out of
the way is caused by the swipe, so the window stood open at exactly the
moment the reader was swiping. The reel moved under the finger, far
enough to show the top of the next video at the bottom of the screen, and
was then pulled back to where it started -- a second later, once the
settle window ran out.
A re-anchor has nothing behind it and a swipe has a finger or a wheel, so
record the input and let a scroll that follows one close the window
instead of being reverted into it. Closing it that way skips the realign,
or the close would undo the swipe that caused it. Only input that means
to scroll counts -- a finger that has moved rather than one that has
merely landed, since a tap must not sign for the re-anchor after it.
Telling a turn apart from the chrome moving was reading the orientation
flip alone, which a few pixels of height cross whenever the viewport is
near enough to square. That pinned the slides and turned snapping off for
a second over a height change, which is the one thing it is there to tell
a turn apart from; a turn swaps the long side, and swapping it moves the
width too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MPZFnNdHbPGDTqQUNiE4ZN
872786a657