1964377 - Update PDF.js to new version 06f44916c8936b92f464d337fe3a0a6b2b78d5b4 from 2025-05-04 12:28:11

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

This update covers 9 commits. Here are the overall diff statistics, and then the commit information.

---

toolkit/components/pdfjs/content/build/pdf.mjs | 16 +-
toolkit/components/pdfjs/content/build/pdf.scripting.mjs | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.mjs | 126 ++++++-------
toolkit/components/pdfjs/content/web/viewer-geckoview.mjs | 6 +-
toolkit/components/pdfjs/content/web/viewer.mjs | 6 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
6 files changed, 76 insertions(+), 86 deletions(-)

---

d9548b1c18b003c20c0d46c6363cde82863617ea by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/d9548b1c18b003c20c0d46c6363cde82863617ea
Authored: 2025-05-04 12:35:00 +0200
Committed: 2025-05-04 13:44:33 +0200

Slightly re-factor how we pre-load fonts and images in XFA documents

Rather than "manually" invoking the methods from the src/core/worker.js file we introduce a single PDFDocument-method that handles this for us, and make the current methods private.
Since this code is only invoked at most once per document, and only for XFA documents, we can use BasePdfManager.prototype.ensureDoc directly rather than needing a stand-alone method.

Files Modified:

• src/core/document.js
• src/core/pdf_manager.js
• src/core/worker.js

---

604153957afee4a2857de343258276d8e813ed63 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/604153957afee4a2857de343258276d8e813ed63
Authored: 2025-05-04 12:34:52 +0200
Committed: 2025-05-04 13:42:17 +0200

Reduce duplication when parsing fonts in loadXfaFonts

Currently we repeat virtually the same code when calling the PartialEvaluator.prototype.handleSetFont method, which we can avoid by introducing an inline helper function.

Files Modified:

• src/core/document.js

---

2979e23f3c9336ede2e5862aa2e721dc6f2942da by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/2979e23f3c9336ede2e5862aa2e721dc6f2942da
Authored: 2025-05-04 12:34:30 +0200
Committed: 2025-05-04 13:42:17 +0200

Ensure that XFAFactory.prototype.isValid returns a boolean value

Considering the name of the method, and how it's actually being used, you'd expect it to return a boolean value.
Given how it's currently being used this inconsistency doesn't cause any issues, however we should still fix this.

Files Modified:

• src/core/xfa/factory.js

---

b3e16800f5123d9b881b7cf6d07860af992d434f by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b3e16800f5123d9b881b7cf6d07860af992d434f
Authored: 2025-05-03 13:35:26 +0200
Committed: 2025-05-03 13:40:23 +0200

Remove the BasePdfManager.prototype.catalog getter

This is only invoked once and it can be trivially replaced by the ensureCatalog-method, since the code where it's used is already asynchronous.

Files Modified:

• src/core/pdf_manager.js
• src/core/struct_tree.js

---

b531720d9c3a07474e96c925c77bba5f5e3bc5a4 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b531720d9c3a07474e96c925c77bba5f5e3bc5a4
Authored: 2025-05-03 11:14:01 +0200
Committed: 2025-05-03 11:20:42 +0200

Simplify the serializeXfaData method and related code

Rather than having a dedicated BasePdfManager-method for this one call-site we can instead change PDFDocument.prototype.serializeXfaData to a non-async method, that we invoke via BasePdfManager.prototype.ensureDoc.

Files Modified:

• src/core/document.js
• src/core/pdf_manager.js
• src/core/worker.js

---

122822a75001d26b83ff7e111476ba90255b1a8b by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/122822a75001d26b83ff7e111476ba90255b1a8b
Authored: 2025-05-02 11:31:45 +0200
Committed: 2025-05-02 11:53:41 +0200

Simplify the loadXfaImages method and related code

Currently we create an intermediate Dict during parsing, however that seems unnecessary since (note especially the second point):

• The NameOrNumberTree.prototype.getAll method will already resolve any references, as needed, during parsing.
• The Catalog.prototype.xfaImages getter is invoked, via the BasePdfManager-instance, such that any MissingDataExceptions are already handled correctly.

Files Modified:

• src/core/catalog.js
• src/core/document.js
• src/core/xfa/template.js

---

7bba3bd4adf85204e3b3d12ed35c740f7d0e1869 by Gautam Panakkal <[e-mail]>

https://github.com/mozilla/pdf.js/commit/7bba3bd4adf85204e3b3d12ed35c740f7d0e1869
Authored: 2025-04-03 20:27:40 -0700
Committed: 2025-05-01 10:19:28 -0700

Add missing this arg to toStyle in CheckButton.prototype.[$toHTML]

Files Modified:

• src/core/xfa/template.js

---

b629bafd1ce7f320c8c609cc8c12d00b947f4f32 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b629bafd1ce7f320c8c609cc8c12d00b947f4f32
Authored: 2025-04-30 15:43:00 +0200
Committed: 2025-04-30 20:51:10 +0200

Allow to, optionally, keep Unicode escape sequences in stringToPDFString (PR 17331 follow-up)

Currently some of the links[1] on page three of the issue19835.pdf test-case aren't clickable, since the destination (of the LinkAnnotation) becomes empty.
The reason is that these destinations include the character \x1b, which is interpreted as the start of a Unicode escape sequence specifying the language of the string; please refer to section 7.9.2.2 Text String Type in the PDF specification.

Hence it seems that we need a way to optionally disable that behaviour, to avoid a "badly" formatted string from becoming empty (or truncated), at least for cases where we are:

• Parsing named destinations[2] and URLs.
• Handling "strings" that are actually /Name-instances.
• Building a lookup Object/Map based on some PDF data-structure.

NOTE: The issue that prompted this patch is obviously related to destinations, however I've gone through the src/core/ folder and updated various other stringToPDFString call-sites that (directly or indirectly) fit the categories listed above.

---

[1] Try clicking on anything on the line containing "Item 7A. Quantitative and Qualitative Disclosures About Market Risk 27".

[2] Unfortunately just skipping stringToPDFString in this case would cause other issues, such as the named destination becoming "unusable" in the viewer; see e.g. issues 14847 and 14864.

Files Modified:

• src/core/catalog.js
• src/core/core_utils.js
• src/core/file_spec.js
• src/shared/util.js
• test/unit/api_spec.js

---

254431df1e6b22eed9a93c202759bd2e87a9f566 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/254431df1e6b22eed9a93c202759bd2e87a9f566
Authored: 2025-04-30 15:26:00 +0200
Committed: 2025-04-30 15:26:00 +0200

Avoid extra lookup/parsing when all destinations are already available

Whenever we cannot find a destination we'll fallback to checking all destinations, to account for e.g. out-of-order NameTrees, and in those cases any subsequent destination-lookups can be made a tiny bit more efficient by immediately checking the already cached destinations.

Files Modified:

• src/core/catalog.js

---

Comment 1

[Update Bot]

I've submitted a try run for this commit: https://treeherder.mozilla.org/jobs?repo=try&revision=60626ad65c639a890a957fca5bc340197f220118

Comment 2

[Update Bot]

Attachment: Bug 1964377 - Update PDF.js to 06f44916c8936b92f464d337fe3a0a6b2b78d5b4

Comment 3

[Update Bot]

The try push is done, we found jobs with unclassified failures.

Needs Close Investigation:

• ShutdownLeaks | process() called before end of test suite

• 1 of 4 failed on the same (retriggered) task
  - test-macosx1015-64-qr/debug-mochitest-browser-chrome-1 (c32WeVr5TMiUihVxc67cDQ)

• did not see DOCSHELL log strings. this occurs if the DOCSHELL logging gets disabled by something. 12 created seen 0 destroyed seen

• 1 of 4 failed on the same (retriggered) task
  - test-macosx1015-64-qr/debug-mochitest-browser-chrome-1 (c32WeVr5TMiUihVxc67cDQ)

Known Issues:

• automation.py
  - test-macosx1015-64-qr/debug-mochitest-browser-chrome-1 (c32WeVr5TMiUihVxc67cDQ)

These failures could mean that the library update changed something and caused
tests to fail. You'll need to review them yourself and decide where to go from here.

In either event, I have done all I can and you will need to take it from here. If you
don't want to land my patch, you can replicate it locally for editing with
./mach vendor toolkit/components/pdfjs/moz.yaml

When reviewing, please note that this is external code, which needs a full and
careful inspection - not a rubberstamp.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/987d5caadc6b
Update PDF.js to 06f44916c8936b92f464d337fe3a0a6b2b78d5b4 r=calixte

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/987d5caadc6b