1915145 - Update PDF.js to new version b58c24ab099c4bd4cefa5139669708227dd9641a from 2024-08-26 13:33:41

Status: RESOLVED DUPLICATE of bug 1916519

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

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

---

taskcluster/kinds/fetch/toolchains.yml | 2 +-
toolkit/components/pdfjs/content/build/pdf.mjs | 18 +-
toolkit/components/pdfjs/content/build/pdf.scripting.mjs | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.mjs | 52 +++++-----
toolkit/components/pdfjs/content/web/viewer-geckoview.mjs | 15 ++-
toolkit/components/pdfjs/content/web/viewer.mjs | 68 ++++++++------
toolkit/components/pdfjs/moz.yaml | 4 +-
toolkit/locales/en-US/toolkit/pdfviewer/viewer.ftl | 22 ++--
8 files changed, 99 insertions(+), 86 deletions(-)

---

e8763a08ab1a2cbbda994874853b60e571296120 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/e8763a08ab1a2cbbda994874853b60e571296120
Authored: 2024-08-25 17:33:42 +0200
Committed: 2024-08-25 17:33:42 +0200

[Editor] Add a missing parameter in the telemetry for the new alt text flow (bug 1914480)

Files Modified:

• src/display/editor/stamp.js
• web/new_alt_text_manager.js

---

6ce9f97943fd04830588dceea510c76e3fcd606b by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/6ce9f97943fd04830588dceea510c76e3fcd606b
Authored: 2024-08-21 21:43:42 +0200
Committed: 2024-08-25 12:11:02 +0200

Utilize Fluent to format dates in the AnnotationLayer

The AnnotationLayer may not display correctly formatted data in PopupAnnotations, especially in the GENERIC viewer, since it's using native methods[1] that depend on the browser locale instead of the viewer locale as intended.
With Fluent we're able to improve things since it's got built-in support for formatting dates. Not only does this simplify the JavaScript code slightly, but it also gives the localizer more fine-grained control of the desired output.

Please find additional information here:

• https://projectfluent.org/fluent/guide/builtins.html
• https://projectfluent.org/fluent/guide/functions.html

---

[1] toLocaleDateString, and toLocaleTimeString.

Files Modified:

• l10n/en-US/viewer.ftl
• src/display/annotation_layer.js

---

d96558836ebd974c058db54c8efec1ca04f9f3ba by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/d96558836ebd974c058db54c8efec1ca04f9f3ba
Authored: 2024-08-21 17:15:32 +0200
Committed: 2024-08-25 12:11:02 +0200

Utilize Fluent to format numbers and dates in PDFDocumentProperties

The PDFDocumentProperties dialog may not display correctly formatted data, especially in the GENERIC viewer, since it's using native methods[1] that depend on the browser locale instead of the viewer locale as intended.
At the time when this dialog was introduced that was probably all we could easily do, but with Fluent we're able to improve things since it's got built-in support for formatting numbers and dates. Not only does this simplify the JavaScript code, but it also gives the localizer more fine-grained control of the desired output.

Please find additional information here:

• https://projectfluent.org/fluent/guide/builtins.html
• https://projectfluent.org/fluent/guide/functions.html

---

[1] toLocaleString, toLocaleDateString, and toLocaleTimeString.

Files Modified:

• l10n/en-US/viewer.ftl
• web/pdf_document_properties.js

---

bf778b04a88a1a5454a265b1c0bc80a7acb463d1 by Tim van der Meij <[e-mail]>

https://github.com/mozilla/pdf.js/commit/bf778b04a88a1a5454a265b1c0bc80a7acb463d1
Authored: 2024-08-25 11:40:42 +0200
Committed: 2024-08-25 11:40:42 +0200

Update translations to the most recent versions

Files Modified:

• l10n/be/viewer.ftl
• l10n/cs/viewer.ftl
• l10n/cy/viewer.ftl
• l10n/da/viewer.ftl
• l10n/de/viewer.ftl
• l10n/dsb/viewer.ftl
• l10n/fi/viewer.ftl
• l10n/fr/viewer.ftl
• l10n/fur/viewer.ftl
• l10n/he/viewer.ftl
• l10n/ia/viewer.ftl
• l10n/it/viewer.ftl
• l10n/kk/viewer.ftl
• l10n/nn-NO/viewer.ftl
• l10n/pa-IN/viewer.ftl
• l10n/pt-PT/viewer.ftl
• l10n/skr/viewer.ftl
• l10n/zh-CN/viewer.ftl

---

c26aac013efe0dea2dc63876400225f9cc15e3e9 by Tim van der Meij <[e-mail]>

https://github.com/mozilla/pdf.js/commit/c26aac013efe0dea2dc63876400225f9cc15e3e9
Authored: 2024-08-25 11:39:06 +0200
Committed: 2024-08-25 11:39:06 +0200

Fix vulnerability in the micromatch dependency

This patch is generated automatically using npm audit fix and fixes
CVE-2024-4067 (see https://github.com/advisories/GHSA-952p-6rrq-rcjv),
bringing the vulnerability count back to zero.

Files Modified:

• package-lock.json

---

5d31fda87677d49d59cd3c1cd3a24bb3b74f1abc by Tim van der Meij <[e-mail]>

https://github.com/mozilla/pdf.js/commit/5d31fda87677d49d59cd3c1cd3a24bb3b74f1abc
Authored: 2024-08-25 11:36:55 +0200
Committed: 2024-08-25 11:38:00 +0200

Update dependencies to the most recent versions

Files Modified:

• gulpfile.mjs
• package-lock.json
• package.json

---

6a1b1ae6a42fcc421d513852b9164be04097b96b by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/6a1b1ae6a42fcc421d513852b9164be04097b96b
Authored: 2024-08-23 18:39:28 +0200
Committed: 2024-08-23 18:39:28 +0200

Revoke the blob-URLs used during printing in PDFPrintService

Files Modified:

• web/pdf_print_service.js

---

502a429e3e87495dfd93da3cbeb19ca93614c536 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/502a429e3e87495dfd93da3cbeb19ca93614c536
Authored: 2024-08-23 13:39:32 +0200
Committed: 2024-08-23 18:29:42 +0200

Use HTMLCanvasElement.toBlob() unconditionally in PDFPrintService

The fallback is very old code, and according to the MDN compatibility data HTMLCanvasElement.toBlob() should be available in all browsers that we support now: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob#browser_compatibility

Files Modified:

• web/pdf_print_service.js

---

8728f7f1342a486e3a3267a7566965182e5fcbfd by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/8728f7f1342a486e3a3267a7566965182e5fcbfd
Authored: 2024-08-23 16:06:54 +0200
Committed: 2024-08-23 16:31:43 +0200

Support an odd number of digits in hexadecimal strings (issue 18645)

See https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#G6.1840792

Files Added:

• test/pdfs/issue18645.pdf

Files Modified:

• src/core/parser.js
• test/pdfs/.gitignore
• test/test_manifest.json
• test/unit/parser_spec.js

---

fabbe544abf90d30b76bfbcadb737fcfa84fbd64 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/fabbe544abf90d30b76bfbcadb737fcfa84fbd64
Authored: 2024-08-23 12:31:55 +0200
Committed: 2024-08-23 12:31:55 +0200

Introduce a L10n-method to translate an element once, and use that in PDFLayerViewer

Currently we manually fetch the "pdfjs-additional-layers" string and update the DOM-element, which was needed since we want to avoid triggering a bunch of otherwise unnecessary translation when appending the entire layer-tree to the DOM.
By introducing a new helper method in the L10n-class we can avoid this, and instead use a "data-l10n-id" attribute on the element (as most other viewer code does nowadays).

Files Modified:

• web/l10n.js
• web/pdf_layer_viewer.js

---

2c34b644159e04316f9677e879956ef0b7cab05c by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/2c34b644159e04316f9677e879956ef0b7cab05c
Authored: 2024-08-21 15:07:46 +0200
Committed: 2024-08-21 15:07:46 +0200

Introduce a helper method for fetching l10n-data in PDFDocumentProperties

Given the length of the l10n-strings we can slightly reduce verbosity, and thus overall code-size, by introducing a helper method for fetching l10n-data.

While testing this I stumbled upon an issue in the L10n-class, where an optional chaining operator was placed incorrectly since the underlying method always return an Array; see https://github.com/projectfluent/fluent.js/blob/48e2a62ed45ff2a62a231b2e83cfd8b332d27acb/fluent-dom/src/localization.js#L38-L77

Files Modified:

• web/l10n.js
• web/pdf_document_properties.js

---

a67b9aec6c5f34d46e8a080f920c3b0e046464b6 by Richard Smith (smir) <[e-mail]>

https://github.com/mozilla/pdf.js/commit/a67b9aec6c5f34d46e8a080f920c3b0e046464b6
Authored: 2024-08-19 15:18:05 +0100
Committed: 2024-08-21 11:08:14 +0100

Send fetch requests for all page dict lookups in parallel - When adding page dict candidates to the lookup tree, also initiate fetching them from xref, so if they are not yet loaded at all, the XHR will be sent - Only at the top level - assume that if there is a /Pages tree, it is sensibly structured and the number of requests won't be too bad - We can then await on the cached Promise without making the requests pipeline - This has a significant performance improvement for load-on-demand (i.e. with auto-fetch turned off) when a PDF has a large number of pages in the top level /Pages collection, and those pages are spread through a file, so every candidate needs to be fetched separately - PDFs with many pages where each page is a big image and all the pages are at the top level are quite a common output for digitisation programmes - I would have liked to do something like "if it's the top level collection and page count = number of kids, then just fetch that page without traversing the tree" but unfortunately I agree with comments on #8088 that there is no good general solution to allow for /Pages nodes with empty /Kids arrays

Files Modified:

• src/core/catalog.js

---

b0c239a20071a62725318c04eb5bfc9813c67c67 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b0c239a20071a62725318c04eb5bfc9813c67c67
Authored: 2024-08-20 22:24:08 +0100
Committed: 2024-08-20 22:24:08 +0100

Don't show the print dialog when printing in some integration tests

Files Modified:

• test/integration/scripting_spec.mjs
• test/integration/test_utils.mjs

---

Comment 1

[Update Bot]

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

Comment 2

[Update Bot]

Attachment: Bug 1915145 - Update PDF.js to b58c24ab099c4bd4cefa5139669708227dd9641a

Comment 3

[Update Bot]

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

Needs Close Investigation:

• toolkit/components/pdfjs/test/browser_pdfjs_alttext_telemetry.js
  • 17 of 17 failed on different tasks
    - test-windows11-64-2009-qr/opt-mochitest-browser-chrome-spi-nw-1 (S9mUsailQk-WxYsHkbKdGQ)
    - test-windows11-64-2009-qr/opt-mochitest-browser-chrome-1 (dusrzGqfRTWmBoJQL_GsYQ)
    - test-macosx1015-64-qr/opt-mochitest-browser-chrome-spi-nw-1 (EMcHt-31TqWJ7AXfc42XhQ)
    - test-macosx1015-64-qr/opt-mochitest-browser-chrome-1 (LQBgOmKuSWWIBHEPOHOTag)
    - test-windows11-32-2009-qr/debug-mochitest-browser-chrome-1 (a8dJpU-fTGOypjrfsWwb3Q)
    - test-linux1804-64-qr/debug-mochitest-browser-chrome-swr-1 (Fh7aFsEFSfiotbjtssUIAA)
    - test-windows11-32-2009-qr/opt-mochitest-browser-chrome-1 (fJpRDAswQWKOoIUIzAOMZA)
    - test-windows11-64-2009-qr/opt-mochitest-browser-chrome-msix-1 (I_tRuc0zTPqv_qK70NwfCA)
    - test-linux1804-64-qr/opt-mochitest-browser-chrome-swr-1 (dCjSSRPUQMCVKIIjCh68rw)
    - test-windows11-64-2009-qr/debug-mochitest-browser-chrome-1 (Ixz97imMQw-jeBSFOX0w0g)
    - test-windows11-64-2009-qr/debug-mochitest-browser-chrome-msix-1 (c5Vl7Q0eRYu5EEnnxODsVw)
    - test-linux1804-64-qr/debug-mochitest-browser-chrome-spi-nw-1 (V0psQfDfSZ2EUt1gNT_sIg)
    - test-macosx1015-64-qr/debug-mochitest-browser-chrome-spi-nw-1 (CQCpBmN5RXyW4zXqBEGEKA)
    - test-macosx1015-64-qr/debug-mochitest-browser-chrome-1 (FHUnbymPT5Gf4WO1D5rKDg)
    - test-linux1804-64-qr/opt-mochitest-browser-chrome-swr-a11y-checks-1 (TW4HYuRBToaE509cq88jWA)
    - test-linux1804-64-qr/opt-mochitest-browser-chrome-spi-nw-1 (GWVXNwxcRkePH2oN4d90zA)
    - test-windows11-64-2009-qr/debug-mochitest-browser-chrome-spi-nw-1 (SUn5gtzFSeG0VvlrPuNSCg)

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

[Update Bot]

This bug is being closed because a newer revision of the library is available.
This bug will be marked as a duplicate of it (because although this bug is older, it is superseded by the newer one).

Comment 5

[Update Bot]

Updatebot encountered an error while trying to abandon the phabricator patch 220252.
Updatebot will be unable to do anything more for this library version.