1949972 - Update PDF.js to new version 878d206c791d71abfd9bdd8932bdcf35402856b6 from 2025-02-22 14:55:26

Status: RESOLVED DUPLICATE of bug 1950129

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

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

---

toolkit/components/pdfjs/content/build/pdf.mjs | 77 +-
toolkit/components/pdfjs/content/build/pdf.scripting.mjs | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.mjs | 183 +-
toolkit/components/pdfjs/content/web/viewer-geckoview.mjs | 714 +++++++--
toolkit/components/pdfjs/content/web/viewer.mjs | 716 +++++++--
toolkit/components/pdfjs/content/web/wasm/openjpeg.wasm | Bin
toolkit/components/pdfjs/content/web/wasm/openjpeg_nowasm_fallback.js | 29 +
toolkit/components/pdfjs/moz.yaml | 4 +-
8 files changed, 1205 insertions(+), 522 deletions(-)

---

301f1bbf2bba1fe6894b26dbec24e32f841ea875 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/301f1bbf2bba1fe6894b26dbec24e32f841ea875
Authored: 2025-02-22 15:19:10 +0100
Committed: 2025-02-22 15:19:14 +0100

[Editor] Fix the position in the page of a drawing after it has been moved with the keyboard

When a drawing was moved with arrow keys and then printed or saved, the drawing wasn't moved finally.
So the fix is just about calling onTranslated once the translation is done.

Files Modified:

• src/display/editor/draw.js
• src/display/editor/editor.js
• src/display/editor/tools.js
• test/integration/freetext_editor_spec.mjs
• test/integration/ink_editor_spec.mjs
• test/integration/test_utils.mjs

---

637e95985a70ce7107b03b7cb2ca610e9f06bddb by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/637e95985a70ce7107b03b7cb2ca610e9f06bddb
Authored: 2025-02-22 13:38:10 +0100
Committed: 2025-02-22 13:38:10 +0100

Simplify JpxImage.setOptions a little bit

After PR 19392 we're only invoking this method once per document, hence the early-return branch shouldn't be necessary any more.

Files Modified:

• src/core/jpx.js
• src/core/pdf_manager.js

---

641e2f506e8c1d384e985374caa963d5ef5f9b2d by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/641e2f506e8c1d384e985374caa963d5ef5f9b2d
Authored: 2025-02-21 23:20:44 +0100
Committed: 2025-02-22 09:56:53 +0100

[api-minor] Re-factor how the useWorkerFetch option is used internally

With the recently added OpenJPEG no-wasm fallback we need to send the wasmUrl option to the worker-thread regardless of the value of the useWorkerFetch option, since the fallback won't work if we don't have a URL to import it from.
For consistency the code is re-factored to always send the factory-urls to the worker-thread, and simply check the useWorkerFetch option there instead.

Also, as a follow-up to PR 19525, introduce a new useWasm option that can be used in e.g. browser-tests to forcibly disable WebAssembly usage.

Files Modified:

• src/core/evaluator.js
• src/core/jpx.js
• src/display/api.js
• test/driver.js
• test/test_manifest.json

---

814d2bbe6d594437423114c6fb59f43b38e51abb by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/814d2bbe6d594437423114c6fb59f43b38e51abb
Authored: 2025-02-21 21:43:16 +0100
Committed: 2025-02-21 21:43:19 +0100

[Editor] Add a test for copy & paste a signature editor

This patch fixes an issue when pasting: an exception was thrown when pasting.
And while writing the test and comparing the paths in the svg, I found a difference
which is fixed thanks to call to the right constructor (to take into account the inheritance)
in inkdraw.js

Files Modified:

• src/display/editor/drawers/inkdraw.js
• src/display/editor/signature.js
• test/integration/signature_editor_spec.mjs

---

24aa39eb14354185f20f1568beeeb72e0bd072bd by Xiphoseer <[e-mail]>

https://github.com/mozilla/pdf.js/commit/24aa39eb14354185f20f1568beeeb72e0bd072bd
Authored: 2025-02-21 20:51:27 +0100
Committed: 2025-02-21 21:31:04 +0100

Consider textRise when showing type3 font glyphs

Add test case for issue 19532

Files Added:

• test/pdfs/issue19532.pdf

Files Modified:

• src/display/canvas.js
• test/pdfs/.gitignore
• test/test_manifest.json

---

36e4f5c222fc48fc514d8723612718256e554397 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/36e4f5c222fc48fc514d8723612718256e554397
Authored: 2025-02-20 22:34:46 +0100
Committed: 2025-02-21 19:03:47 +0100

Provide a js fallback when the wasm version of openjpeg is failing to load (bug 1935076)

Files Added:

• external/openjpeg/openjpeg_nowasm_fallback.js

Files Modified:

• eslint.config.mjs
• external/openjpeg/openjpeg.js
• external/openjpeg/openjpeg.wasm
• gulpfile.mjs
• src/core/jpx.js
• test/driver.js
• test/test_manifest.json

---

dc5d6aad8acf91cbf704a1da258b6cec50d7efe2 by Nicolò Ribaudo <[e-mail]>

https://github.com/mozilla/pdf.js/commit/dc5d6aad8acf91cbf704a1da258b6cec50d7efe2
Authored: 2025-01-16 11:26:19 +0100
Committed: 2025-02-21 10:00:57 -0800

Avoid degrading scroll performance due to the detail view

When scrolling quickly, the constant re-rendering of the detail view
significantly affects rendering performance, causing Firefox to
not render even the background canvas, which is just a static canvas
not being re-drawn by JavaScript.

This commit changes the viewer to only render the detail view while
scrolling if its rendering hasn't just been cancelled. This means that:

• when the user is scrolling slowly, we have enough time to render the
  detail view before that we need to change its area, so the user always
  sees the full screen as high resolution.
• when the user is scrolling quickly, as soon as we have to cancel a
  rendering we just give up, and the user will see the lower resolution
  canvas. When then the user stops scrolling, we render the detail view
  for the new visible area.

Files Modified:

• web/pdf_page_detail_view.js
• web/pdf_rendering_queue.js
• web/pdf_thumbnail_viewer.js
• web/pdf_viewer.js

---

458b2ee4028b7ba8acf56cb3b22d720358901c2b by Nicolò Ribaudo <[e-mail]>

https://github.com/mozilla/pdf.js/commit/458b2ee4028b7ba8acf56cb3b22d720358901c2b
Authored: 2024-12-11 13:58:52 +0100
Committed: 2025-02-21 10:00:55 -0800

[api-minor] Render high-res partial page views when falling back to CSS zoom (bug 1492303)

When rendering big PDF pages at high zoom levels, we currently fall back
to CSS zoom to avoid rendering canvases with too many pixels. This
causes zoomed in PDF to look blurry, and the text to be potentially
unreadable.

This commit adds support for rendering part of a page (called
PDFPageDetailView in the code), so that we can render portion of a
page in a smaller canvas without hiting the maximun canvas size limit.

Specifically, we render an area of that page that is slightly larger
than the area that is visible on the screen (100% larger in each
direction, unless we have to limit it due to the maximum canvas size).
As the user scrolls around the page, we re-render a new area centered
around what is currently visible.

Files Added:

• test/pdfs/colors.pdf
• web/pdf_page_detail_view.js

Files Modified:

• src/display/api.js
• test/integration/test_utils.mjs
• test/integration/viewer_spec.mjs
• test/pdfs/.gitignore
• test/unit/ui_utils_spec.js
• web/app.js
• web/app_options.js
• web/base_pdf_page_view.js
• web/pdf_page_view.js
• web/pdf_rendering_queue.js
• web/pdf_viewer.js
• web/ui_utils.js

---

06257f782e91811906d04aec6dbb5223c4b7ca53 by Nicolò Ribaudo <[e-mail]>

https://github.com/mozilla/pdf.js/commit/06257f782e91811906d04aec6dbb5223c4b7ca53
Authored: 2024-12-11 13:54:50 +0100
Committed: 2025-02-21 09:48:31 -0800

Extract PDFPageViewBase class out of PDFPageView

This base class contains the generic logic for:

• Creating a canvas and showing when appropriate
• Rendering in the canvas
• Keeping track of the rendering state

Files Added:

• web/base_pdf_page_view.js

Files Modified:

• web/pdf_page_view.js

---

93a5fa5b88020c623c0b9f244bffa0e1c0a3e66d by Christophe Coevoet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/93a5fa5b88020c623c0b9f244bffa0e1c0a3e66d
Authored: 2025-02-21 14:10:35 +0100
Committed: 2025-02-21 14:10:35 +0100

Disable the loading of node types in the type tests

Those type tests are performing type checking on a project using DOM APIs, intended to reflect the usage in a non-node project.
Not loading the node types in that project ensures that the library type declarations don't force a dependency on the node types.

Files Modified:

• test/types/tsconfig.json

---

c2e33307b1b4dc1a815c4af9a9118972ce2cab66 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/c2e33307b1b4dc1a815c4af9a9118972ce2cab66
Authored: 2025-02-15 10:49:30 +0100
Committed: 2025-02-15 19:10:36 +0100

Introduce some URL.parse() usage in the code-base

This (fairly new) static method allows parsing URLs without having to wrap new URL(...) calls within try...catch blocks, thus simplifying the code; see https://developer.mozilla.org/en-US/docs/Web/API/URL/parse_static

For older browsers/environments the functionality will be polyfilled, but only in legacy builds, via core-js; see https://github.com/zloirock/core-js?tab=readme-ov-file#url-and-urlsearchparams

Please note: This is currently limited to the src/- and web/-folders, such that we don't break development/testing, since the functionality is not available in all Node.js versions that we support; see https://developer.mozilla.org/en-US/docs/Web/API/URL/parse_static#browser_compatibility

Files Modified:

• src/display/api.js
• src/display/display_utils.js
• src/display/network_utils.js
• src/shared/util.js
• web/app.js

---

Comment 1

[Update Bot]

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

Comment 2

[Update Bot]

Attachment: Bug 1949972 - Update PDF.js to 878d206c791d71abfd9bdd8932bdcf35402856b6

Comment 3

[Update Bot]

All the jobs in the try run succeeded. Like literally all of them, there weren't
even any intermittents. That is pretty surprising to me, so maybe you should double
check to make sure I didn't misinterpret things and that the correct tests ran...

Anyway, I've done all I can, so I'm passing to you to review and land the patch.
When reviewing, please note that this is external code, which needs a full and
careful inspection - not a rubberstamp.