PDF unscrollable, 'stuck' at certain pages

[lrehmann]

Link to PDF file here: https://manuals.plus/m/bd73fb00d867df453ee8b9b753f761cdf4c3d919f5a5bc956c63d7d87ad45e59.pdf

Configuration:

• Web browser and its version: Firefox 94.0.2 (64-bit), (Also Tried Chrome and Chrome Canary)
• Operating system and its version: OSX Big Sur 11.4 (20F71)
• PDF.js version: whatever ships with 94.0.2 (64-bit) Firefox
• Is a browser extension: No

Steps to reproduce the problem:

1. Load the PDF, embedded navigation script will force you to page 146
2. Accept the alert dialog
3. PDF will be un-scrollable, stuck at 'Cautions & Warnings' pages (pg 146,147,148)

What is the expected behavior? (add screenshot)
User should be able to freely scroll all PDF pages

What went wrong? (add screenshot)
View-window gets 'stuck' on a particular page

I suspect there may be some javascript imbedded in this PDF forcing a scroll to a certain page in order to view the 'Cautions & Warnings' page. Though this could be a poorly coded PDF file, the PDF reader shouldn't allow embedded code to break the user interface.

[Snuffleupagus]

Oof, that's really not good. (I get the same behaviour in Adobe Reader, but still not at all a good UX.)
Looking at the document, all pages contain the following bad JS; @calixteman any ideas for a good/simple work-around?

[calixteman]

A possible workaround is to disable javascript execution.
In Firefox, about:config, change the option pdfjs.enableScripting to false.
The main problem with this file is that there are no action bound in the OK button on the last page.
In Acrobat, once the OK button is pressed, we've access to all the pdf.

After digging, the button itself has no action but there is a Link annotation (id 20) on top of the button.
We only added JS support for fields (our goal was mainly to help with form validation) but not for annotations in general and unfortunately a Link is not a field (when a button is):
https://github.com/mozilla/pdf.js/blob/master/src/core/annotation.js#L2497-L2514

It shouldn't be that hard to implement but it'd require some time...
I'm attaching the pdf here to be sure to have it when I'll have some time to fix this issue.
bd73fb00d867df453ee8b9b753f761cdf4c3d919f5a5bc956c63d7d87ad45e59.pdf

[lrehmann]

I appreciate the digging that has been done to understand this issue. Thank you @calixteman & @Snuffleupagus

[calixteman]

Right now, we collect fields from the Fields dict (which has a tree structure) and pageActions from the pages Dict (we just look for A or AA entries which are arrays or linked list of arrays (in using Next)).
So it's possible to try to find all the annotations which are not a field in inspecting all the tree to find out all the possible actions.
Once we've all the JS actions we can add them in the sandbox as we do for the pageActions and add some code to trigger them from the annotation_layer: it's easy.
One concern I have is that it means that we must parse all the pdf to find those actions and since we have no clue on their presence we should do that for every pdf... I've the feeling it could have an impact on overall performance.

An other possibility could be to send to the sandbox the action when we discover it which means we would have to create a sandbox if none is existing. It could induce a performance penalty when the containing page is open and maybe we should have a way to be sure the sandbox is ready when an event is triggered by the user.

@Snuffleupagus, @timvandermeij, @brendandahl any thoughts ?

[Snuffleupagus]

One concern I have is that it means that we must parse all the pdf to find those actions and since we have no clue on their presence we should do that for every pdf... I've the feeling it could have an impact on overall performance.

Yes, that will affect performance really badly and is basically a non-starter since it'd completely break all of the (painstakingly implemented) lazy loading/initialization of PDF documents.
Imagine e.g. a thousand page document, where we'd then need to initialize/parse (on the worker-thread) every single page before we can start loading/rendering it in the viewer!

An other possibility could be to send to the sandbox the action when we discover it which means we would have to create a sandbox if none is existing.

How likely is it that the sandbox hasn't already been initialized in these cases, since e.g. the PDF document in this issue should have caused it to be initialized "normally" already?

It could induce a performance penalty when the containing page is open and maybe we should have a way to be sure the sandbox is ready when an event is triggered by the user.

I could be wrong, but it seems that the cases where that "performance penalty" is induced would be quite few and far between. It most definitely seems appropriate to let those (few) cases take a one-time hit for initializing the sandbox, rather than every single PDF document ever opened in Firefox (a vast majority of which contain no scripts whatsoever).