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

Access the XRef/Catalog data correctly in the "GetStats"/"GetPageIndex" handlers in src/core/worker.js #12276

Merged
merged 2 commits into from
Aug 25, 2020

Conversation

Snuffleupagus
Copy link
Collaborator

  • Access the XRef data correctly in the "GetStats" handler in src/core/worker.js

    Even though the code obviously works as-is, given that we have unit-tests for it, it still feels incorrect to just assume that the XRef-instance has all of its properties immediately available. Especially when (almost) all of the other handlers, in src/core/worker.js, protect their data accesses with appropriate pdfManager.ensure calls.

  • Access the Catalog data correctly in the "GetPageIndex" handler in src/core/worker.js

    Even though the code obviously works as-is, given that we have unit-tests for it, it still feels incorrect to just assume that the Catalog-instance has all of its properties immediately available. Especially when (almost) all of the other handlers, in src/core/worker.js, protect their data accesses with appropriate pdfManager.ensure calls.

…re/worker.js`

Even though the code obviously works as-is, given that we have unit-tests for it, it still feels incorrect to just *assume* that the `XRef`-instance has all of its properties immediately available. Especially when (almost) all of the other handlers, in `src/core/worker.js`, protect their data accesses with appropriate `pdfManager.ensure` calls.
…`src/core/worker.js`

Even though the code obviously works as-is, given that we have unit-tests for it, it still feels incorrect to just *assume* that the `Catalog`-instance has all of its properties immediately available. Especially when (almost) all of the other handlers, in `src/core/worker.js`, protect their data accesses with appropriate `pdfManager.ensure` calls.
@Snuffleupagus
Copy link
Collaborator Author

/botio unittest

@pdfjsbot
Copy link

From: Bot.io (Windows)


Received

Command cmd_unittest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.215.176.217:8877/32e5770729f5b9d/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_unittest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/6d098b166e5be77/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/6d098b166e5be77/output.txt

Total script time: 3.77 mins

  • Unit Tests: Passed

@pdfjsbot
Copy link

From: Bot.io (Windows)


Success

Full output at http://54.215.176.217:8877/32e5770729f5b9d/output.txt

Total script time: 4.87 mins

  • Unit Tests: Passed

@timvandermeij timvandermeij merged commit 525cc73 into mozilla:master Aug 25, 2020
@timvandermeij
Copy link
Contributor

I agree; thanks!

@Snuffleupagus Snuffleupagus deleted the worker-ensure branch August 26, 2020 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants