Fix initial page drift in PDF scroll mode#206
Open
alea12 wants to merge 1 commit into
Open
Conversation
In scrolling mode, navigating to a start page performed a single scrollTo as soon as the first page rendered. While the PDF streams in, placeholders are swapped for rendered pages and the fit-mode resize changes every page's height, shifting the target page after the scroll already happened. The viewport then landed a dozen or more pages past the requested one, and PAGE_IN_VIEW locked that wrong page number in. Keep the target page anchored by re-checking its position every frame and correcting the scroll offset until the layout has been stable for ANCHOR_SETTLE_MS, or until the user interacts with the reader (wheel, touch, mouse, or keyboard). Each correction also refreshes the programmatic-navigation guard so PAGE_IN_VIEW does not override the target page mid-anchoring.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When the reader opens with a
startpage in scroll mode (e.g. a manifestreadingOrderhref with?start=00000262), the viewer initially shows the requested page number but then drifts to a later page (262 → 274/345 depending on viewport) once the PDF finishes loading.Cause
The scroll effect performed a single
scrollToto the target page as soon as the first page rendered (state.rendered). At that moment page slot heights are still provisional: placeholders are later swapped for rendered pages, and the fit-mode resize (RESIZE_PAGE) changes every page's height. The layout shift after the one-shot scroll leaves the viewport several pages past the target (measured ~5,900px = 12.4 pages past page 262 with a 480px slot pitch).PAGE_IN_VIEWthen reports the wrong visible page and, because it setsisInViewUpdate, the corrective re-scroll is skipped.The drift amount depends on the ratio between provisional and final slot heights, which is why different viewports land on different pages.
Fix
Keep the target page anchored instead of scrolling once:
ANCHOR_SETTLE_MS(1s), or immediately when the user interacts with the reader (wheel/touchstart/mousedown/keydown), so user scrolling is never hijacked.lastProgrammaticNavAt/lastVisiblePage/ratios(same asbeginProgrammaticNavigation), soPAGE_IN_VIEWcannot override the target mid-anchoring.Verification
Tested against DRB enhanced-search locally with
/item/...?previewItemId=25443668&previewPage=00000262(516-page PDF):scrollTopovershot page 262's offset by 12.4 pages.scrollTop== page 262 offset, delta 0px) and stays there; manual scrolling afterwards is not pulled back.jest --ci: 9 suites / 27 tests pass.🤖 Generated with Claude Code