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

---

toolkit/components/pdfjs/content/build/pdf.js | 109 ++++----------
toolkit/components/pdfjs/content/build/pdf.scripting.js | 6 +-
toolkit/components/pdfjs/content/build/pdf.worker.js | 49 +-----
toolkit/components/pdfjs/content/web/viewer-geckoview.js | 6 +-
toolkit/components/pdfjs/content/web/viewer.html | 2 +-
toolkit/components/pdfjs/content/web/viewer.js | 6 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
7 files changed, 53 insertions(+), 129 deletions(-)

---

24b480fabe152b0d38d448eb6b963eb5de933c47 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/24b480fabe152b0d38d448eb6b963eb5de933c47
Authored: 2023-08-23 16:00:52 -0400
Committed: 2023-08-24 09:10:27 -0400

Don't reset all fields when the resetForm argument is an array

correctly set the readonly property in the annotation layer and set the default checkbox value to Off when none is provided.

Files Added:

• test/pdfs/issue16863.pdf.link

Files Modified:

• src/core/annotation.js
• src/display/annotation_layer.js
• src/scripting_api/doc.js
• test/integration/scripting_spec.js
• test/test_manifest.json

---

ee3ac35e0553f5614c58a76952da451a35529466 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/ee3ac35e0553f5614c58a76952da451a35529466
Authored: 2023-08-23 11:14:29 -0400
Committed: 2023-08-23 12:34:41 -0400

Revert fix for bug 1838855 (bug 1849876)

The issue described in the mentioned bug is reall because
Acrobat is rendering the XFA instead of the Acroform.
The original patch just tried to workaround the issue but it
induces some regressions.

Files Modified:

• src/core/annotation.js
• src/core/document.js
• src/display/annotation_layer.js
• test/integration/annotation_spec.js
• test/unit/api_spec.js

---

89779b3f6c51b8867f39a6a8b9ed6b8accbcf179 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/89779b3f6c51b8867f39a6a8b9ed6b8accbcf179
Authored: 2023-08-23 11:22:25 +0200
Committed: 2023-08-23 11:22:25 +0200

Add the .mjs file-extension to the EditorConfig

Given that this file-extension is used for JavaScript modules, those files should obviously be formatted just like any "normal" JS file.

Files Modified:

• .editorconfig

---

de52c98ddf32b59535b742a27906ffdeca0a718b by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/de52c98ddf32b59535b742a27906ffdeca0a718b
Authored: 2023-08-22 10:05:21 +0200
Committed: 2023-08-22 10:05:21 +0200

Add the "aria-controls" attribute to the StampEditor toolbar-button

Given that the other Editor toolbar-buttons use this attribute, it seems that the StampEditor should as well.

Files Modified:

• web/viewer.html

---

cd181eb74632789a6c64b10d56b01ec5eddbaa04 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/cd181eb74632789a6c64b10d56b01ec5eddbaa04
Authored: 2023-08-21 10:07:25 +0200
Committed: 2023-08-21 10:15:04 +0200

Exclude lineEndings, in Annotation-data, in MOZCENTRAL builds (PR 14899 follow-up)

This was added in PR 14899, over a year ago, however it's still completely unused in the PDF.js library/viewer. In hindsight I think that it was a mistake to add unused functionality, and the issue should probably have been WONTFIXed instead, however we probably can't just remove it now.
Thanks to the pre-processor, we can at least exclude this code in the built-in Firefox PDF Viewer.

Files Modified:

• src/core/annotation.js

---

988ce2820ba2085ed8d21413abc100970dafefe1 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/988ce2820ba2085ed8d21413abc100970dafefe1
Authored: 2023-08-19 16:18:38 +0200
Committed: 2023-08-19 16:18:38 +0200

Initialize the PDFWorker.#workerPorts WeakMap lazily

By default this WeakMap isn't needed, and it's simple enough to initialize it lazily instead.

Files Modified:

• src/display/api.js

---

2993c7725b48baed5010d8531500bc33b17b2881 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/2993c7725b48baed5010d8531500bc33b17b2881
Authored: 2023-08-19 15:52:00 +0200
Committed: 2023-08-19 15:52:00 +0200

[Firefox] Exclude more workerPort related code in MOZCENTRAL builds

Given that this code is (and has always been) unused in the Firefox PDF Viewer, we don't need to include it in that build-target.

Files Modified:

• src/display/api.js

---

d762986bb09b172c907ac17c93a49a6f5cae1839 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/d762986bb09b172c907ac17c93a49a6f5cae1839
Authored: 2023-08-19 09:15:20 +0200
Committed: 2023-08-19 09:30:41 +0200

Update l10n files

Files Modified:

• l10n/be/viewer.properties
• l10n/cs/viewer.properties
• l10n/cy/viewer.properties
• l10n/da/viewer.properties
• l10n/de/viewer.properties
• l10n/dsb/viewer.properties
• l10n/en-GB/viewer.properties
• l10n/eo/viewer.properties
• l10n/es-AR/viewer.properties
• l10n/es-CL/viewer.properties
• l10n/fi/viewer.properties
• l10n/fr/viewer.properties
• l10n/fy-NL/viewer.properties
• l10n/gn/viewer.properties
• l10n/he/viewer.properties
• l10n/hsb/viewer.properties
• l10n/hu/viewer.properties
• l10n/ia/viewer.properties
• l10n/is/viewer.properties
• l10n/it/viewer.properties
• l10n/ja/viewer.properties
• l10n/ka/viewer.properties
• l10n/kk/viewer.properties
• l10n/ko/viewer.properties
• l10n/nl/viewer.properties
• l10n/pl/viewer.properties
• l10n/pt-BR/viewer.properties
• l10n/pt-PT/viewer.properties
• l10n/rm/viewer.properties
• l10n/ru/viewer.properties
• l10n/sc/viewer.properties
• l10n/sk/viewer.properties
• l10n/sl/viewer.properties
• l10n/sv-SE/viewer.properties
• l10n/tg/viewer.properties
• l10n/uk/viewer.properties
• l10n/vi/viewer.properties
• l10n/zh-CN/viewer.properties
• l10n/zh-TW/viewer.properties

---

4d19db0b1939230b92826a22945a475f694ff52a by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/4d19db0b1939230b92826a22945a475f694ff52a
Authored: 2023-08-19 09:08:54 +0200
Committed: 2023-08-19 09:30:34 +0200

Re-format the code to account for prettier and globals updates

The prettier update slightly changed the formatting of some await-expressions; please see https://github.com/prettier/prettier/blob/main/CHANGELOG.md#302

The globals update removed the need for some eslint-disable statements; please see https://github.com/sindresorhus/globals/releases/tag/v13.21.0

Files Modified:

• src/core/document.js
• src/core/writer.js
• test/unit/pdf_find_controller_spec.js
• web/pdf_link_service.js

---

c5ebfa51a798df41a7fe801996c7e0429ce5766c by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/c5ebfa51a798df41a7fe801996c7e0429ce5766c
Authored: 2023-08-19 09:08:11 +0200
Committed: 2023-08-19 09:08:11 +0200

Update npm packages

Files Modified:

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

---

d513899fc78ac512b96d11d86f4b83cbc13a0839 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/d513899fc78ac512b96d11d86f4b83cbc13a0839
Authored: 2023-08-17 09:11:30 +0200
Committed: 2023-08-17 09:25:58 +0200

Update the StampEditor.isEmpty method to handle File (PR 16828 follow-up)

After the changes in PR 16828 the StampEditor can now be initialized with a File, in addition to a URL, hence it seems that the isEmpty method ought to take that property into account as well.

Looking at this I also noticed that the assignment in the constructor may cause the this.#bitmapUrl/this.#bitmapFile fields be undefined which "breaks" the comparisons in the isEmpty method.
We could obviously fix those specific cases, but it seemed overall safer (with future changes) to just update the isEmpty method to be less sensitive to exactly how these fields are initialized and reset.

Files Modified:

• src/display/editor/stamp.js

---

df9cb772d9ad04b73acd8e593ee24766b2c5b4bb by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/df9cb772d9ad04b73acd8e593ee24766b2c5b4bb
Authored: 2023-08-16 09:58:13 +0200
Committed: 2023-08-17 08:36:07 +0200

Add a helper method to reduce duplication in StampEditor.#getBitmap

Currently we're repeating virtually the same code four times when fetching the bitmap-data, which seems unnecessary.

Also, ensure that the #bitmapPromise is always nulled by moving that into the StampEditor.#getBitmapDone method.

Files Modified:

• src/display/editor/stamp.js

---

2422492ee35cb1e40a979dea473000436be955b5 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/2422492ee35cb1e40a979dea473000436be955b5
Authored: 2023-08-15 12:13:36 +0200
Committed: 2023-08-15 12:45:54 +0200

Add a unit-test for the "correct" way of using the global workerPort in parallel (PR 16830 follow-up)

Please note that for performance reasons it's not really advised to use the same worker-thread in parallel for parsing multiple PDF documents, since they will then unnecessarily compete for resources.
However, given that it's still possible to do that e.g. when using the global workerPort it probably won't hurt to add a unit-test for this particular situation.

Files Modified:

• test/unit/api_spec.js

---

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

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.

https://hg.mozilla.org/mozilla-central/rev/0675ede28916