Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid the getJavaScript API-call in PDFViewerApplication._initializeAutoPrint when "enableScripting" is set #12765

Conversation

Snuffleupagus
Copy link
Collaborator

Rather than calling getJavaScript in the API and then ignoring the result, when "enableScripting" is set, it should be more efficient/faster to simply skip it altogether instead.

Finally, the setTimeout call at the end of PDFViewerApplication._initializeAutoPrint is removed, since it doesn't seem necessary any more as far as I can tell.[1]
Note that when this functionality was originally added, back in PR #2839, it seems that pagesPromise simply waited for the getPage calls of all pages to resolve. Today, on the other hand, the viewer fetches and renders the first page before doing the remaining getPage calls, and only afterwards is pagesPromise resolved. Hence it's not really clear why we now need to delay printing even further with a setTimeout call.


[1] The patch was tested with the following documents: https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug1001080.pdf and https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6106.pdf

…zeAutoPrint` when "enableScripting" is set

Rather than calling `getJavaScript` in the API and then ignoring the result, when "enableScripting" is set, it should be more efficient/faster to simply skip it altogether instead.

Finally, the `setTimeout` call at the end of `PDFViewerApplication._initializeAutoPrint` is removed, since it doesn't seem necessary any more as far as I can tell.[1]
Note that when this functionality was originally added, back in PR 2839, it seems that `pagesPromise` simply waited for the `getPage` calls of *all* pages to resolve. Today, on the other hand, the viewer fetches *and* renders the first page *before* doing the remaining `getPage` calls, and only afterwards is `pagesPromise` resolved. Hence it's not really clear why we now need to delay printing even further with a `setTimeout` call.

---
[1] The patch was tested with the following documents: https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug1001080.pdf and https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6106.pdf
@brendandahl brendandahl merged commit 9c99df7 into mozilla:master Dec 21, 2020
@Snuffleupagus Snuffleupagus deleted the _initializeAutoPrint-scripting-tweaks branch December 22, 2020 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants