Incorrect Page Displayed with Thumbnail View use-cases in Actual Mobile / Chrome Mobile Simulator's

[umedSut]

Hi @stephanrauh ,

Good Day.

PDF Viewer configured at my end:

<ngx-extended-pdf-viewer [authorization]="someToken"
[src]="'someDoc.pdf'" [textLayer]="true" 
(pagesLoaded)="onPagesLoaded($event)" (pageChange)="onPageChange($event)"
[customSidebar]="fancySidebar" [zoom]="auto">

I am facing the following issue in ngx-extended-pdf-viewer in the following scenario.
Issue observed for Actual Mobile Device / Chrome Mobile Simulator only with sidebar thumbnail view.

I have Big PDF Size more than 32 pages.

Please Find Below points for Reproducer:

Issue 1 :
On Actual Mobile Device / Chrome Mobile Simulator. suppose i am on page 1 and after that opened thumbnail view.
Scroll down to thumbnail view pages and click on last page 32. (Right side main content is auto fit on device container height for me its fit 3 pages on right)
Closed the Thumbnail View
Observed that Page 30 is displayed in PDF Viewer.
But the Expectation was Page 32 should displayed because I clicked on page 32 on thumbnail view.

Issue 2:
On Actual Mobile Device / Chrome Mobile Simulator. suppose i am on page 1 and after that opened thumbnail view.
Scroll down the Right side Main Content pages to the last page continuously, and scroll back to the top of the viewer.
some time observed that Page number is not properly showing on Input Fields. (Its an Intermediate issue observed)

Repeat this scroll behavior 2 or 3 time, most of the time it showing wrong page number bind to input fields,

I have checked the below pdf js library (Issue Not Reproducible on JS library because Thumbnail View is displayed on top of Main Contents)
https://mozilla.github.io/pdf.js/web/viewer.html

[stephanrauh]

I'm not sure I can do much about it, but you're right, that's an unexpected behavior, and maybe even annoying. When changing the zoom setting, the PDF viewer always looks at the top-most page that's at least 50% visible. After resizing, it moves that page into view again, and adjusts the page number accordingly.

In your case, three pages are visible. Closing the toolbar triggers a resize event, and as a consequence, the PDF viewer sets the current page number to 30 instead of 32.

If that's a major issue to you, you can try to create a workaround:

• Catch (pageChange) and keep track of the page number - but only if the sidebar is visible.
• Catch the (sidebarVisibleChange) event. I believe (without having tested it) this event is called after changing the zoom setting. So if $event === false, you can set the page number to the old page number (i.e. the page number you've tracked above).

To me, this sounds like a clumsy workaround, but it might work.

Issue 2 is probably similar. The page number field changes when at least 50% of a new page become visible. Does this make sense? Is it what you're observing?

[stephanrauh]

I wonder what I can do for you. Three things come to mind:

1. Implement an event that's triggered before toggling the sidebar, so you can store the page number before resizing.
2. Optionally implement the overlay mode of the thumbnails. So you can opt in for the behavior you've seen on the pdf.js showcase.
3. Implement a "freeze page number on resizing" feature. I'll keep this in mind, but I think that's a bit over the top. At the moment, I don't even have a clue to to call this attribute such that everybody understand what it does. Convince me if I'm wrong!

I haven't made up my mind yet, but I think I'd like to implement the optional overlay, and I'm considering implementing the (beforeSidebarVisibleChange) event. The "free page number" option is on hold, unless you convince me to do it.