A viewport change re-anchors the reel on the video that is playing,
resolved by id rather than by a scroll position the change has already
invalidated. That is what keeps a rotation on the same video.
Mid-swipe it names the wrong one. setActive runs from onScroll's next
frame, so a resize landing before that frame still reads the video being
swiped *away from* -- and realignToActive writes its position straight to
scrollTop, hauling the reel back to it. A phone slides its chrome on every
scroll, so the resize lands mid-swipe on nearly every swipe: the reel went
where the thumb put it, far enough to show the top of the next video at
the bottom of the screen, and was then written back a beat later.
The input guard in onScroll could not catch this. There is no scroll event
to guard -- the write happens inside the resize.
So while the reader is demonstrably driving, take the reel's own position
as the authority and re-anchor on the step it is nearest at the new
height. It still lands on a snap point, so nothing is left straddling two
screens, but the swipe stands. Only a step's worth of disagreement counts
as theirs: a scroller just re-parented into or out of the
picture-in-picture window reads 0, and following that would land them on
the first video instead of their own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MPZFnNdHbPGDTqQUNiE4ZN
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
