872786a657
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