Repository navigation
Ensure that Wasm-decoding of images work if multiple PDFs are parsed in parallel in one worker-thread (fixes issue 22131) - #22145
Merged
Conversation
Codecov Reportβ
All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #22145 +/- ##
==========================================
- Coverage 90.30% 90.21% -0.09%
==========================================
Files 277 277
Lines 67949 67956 +7
==========================================
- Hits 61360 61309 -51
- Misses 6589 6647 +58
Flags with carried forward coverage won't be shown. Click here to find out more. β View full report in Codecov by Harness. π New features to boost your workflow:
|
sync-pdfs-for-pdf-js Bot
pushed a commit
to mozilla/pdf.js.refs
that referenced
this pull request
Oct 11, 2026
Contributor
Viewer previewποΈ Viewer previews removed. |
Snuffleupagus
force-pushed
the
issue-22131
branch
from
October 11, 2026 18:51
20b09b9 to
537e08c
Compare
sync-pdfs-for-pdf-js Bot
pushed a commit
to mozilla/pdf.js.refs
that referenced
this pull request
Oct 11, 2026
β¦in parallel in one worker-thread (fixes issue 22131) The issue only applies when *a single* worker-thread is used to parse multiple PDF documents *in parallel*, and with `useWorkerFetch = false` set, which is *always a bad idea* since the PDFs will then compete for parsing resources and thus slow things down. This only applies in the following situations: - In Node.js environments, where fake-workers are used. - In browsers, if the user manually loads the `pdf.worker.mjs` into the main-thread; this is however NOT supported. - When using `GlobalWorkerOptions.workerPort`, or when manually passing the same `worker` option to multiple `getDocument` calls. For users affected by this issue the best performing solution would be to either ensure that every `getDocument` invocation uses its own worker-thread, or that PDFs are parsed in series if workers aren't available. *Please note:* This could be seen as a hack, since the "correct" solution would be to ensure that the `WasmImage` class always uses the `MessageHandler` that correspond to the currently parsed PDF. Fixing that would however result in a lot of code and complexity, for a use-case that doesn't apply to the Firefox PDF Viewer, hence we cheat a bit by falling back to any active `MessageHandler`. While it may not be the "right" one, it should still work fine in general (unless each `getDocument` invocation uses a unique `BinaryDataFactory`, which seems like a weird enough use-case that we don't bother with it).
Snuffleupagus
force-pushed
the
issue-22131
branch
from
October 11, 2026 19:13
537e08c to
9851e5e
Compare
sync-pdfs-for-pdf-js Bot
pushed a commit
to mozilla/pdf.js.refs
that referenced
this pull request
Oct 11, 2026
Snuffleupagus
temporarily deployed
to
sync_pdfs
October 11, 2026 19:15 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
Contributor
Reference testsResults for 9851e5e (run, references from mozilla/pdf.js.refs@a836b1e6b7).
The report is kept for 30 days and replaced by the next run. |
sync-pdfs-for-pdf-js Bot
pushed a commit
to mozilla/pdf.js.refs
that referenced
this pull request
Oct 11, 2026
sync-pdfs-for-pdf-js Bot
pushed a commit
to mozilla/pdf.js.refs
that referenced
this pull request
Oct 12, 2026
This was referenced Nov 3, 2026
This branch was previously deployed
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
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.
The issue only applies when a single worker-thread is used to parse multiple PDF documents in parallel, and with
useWorkerFetch = falseset, which is always a bad idea since the PDFs will then compete for parsing resources and thus slow things down.This only applies in the following situations:
pdf.worker.mjsinto the main-thread; this is however NOT supported.GlobalWorkerOptions.workerPort, or when manually passing the sameworkeroption to multiplegetDocumentcalls.For users affected by this issue the best performing solution would be to either ensure that every
getDocumentinvocation uses its own worker-thread, or that PDFs are parsed in series if workers aren't available.Please note: This could be seen as a hack, since the "correct" solution would be to ensure that the
WasmImageclass always uses theMessageHandlerthat correspond to the currently parsed PDF.Fixing that would however result in a lot of code and complexity, for a use-case that doesn't apply to the Firefox PDF Viewer, hence we cheat a bit by falling back to any active
MessageHandler. While it may not be the "right" one, it should still work fine in general (unless eachgetDocumentinvocation uses a uniqueBinaryDataFactory, which seems like a weird enough use-case that we don't bother with it).