1929709 - Update PDF.js to new version bff673896614b4b8c30f28397471cb89922a9a31 from 2024-11-06 11:12:45

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

This update covers 40 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 | 1974 ++++++------
toolkit/components/pdfjs/content/build/pdf.scripting.mjs | 193 +-
toolkit/components/pdfjs/content/build/pdf.worker.mjs | 215 +-
toolkit/components/pdfjs/content/web/viewer-geckoview.mjs | 29 +-
toolkit/components/pdfjs/content/web/viewer.css | 1 +
toolkit/components/pdfjs/content/web/viewer.mjs | 29 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
toolkit/locales/en-US/toolkit/pdfviewer/viewer.ftl | 11 +-
9 files changed, 1258 insertions(+), 1200 deletions(-)

---

6d7157a875c75679c7b0d3d15454db2ca62fbd37 by Pascal Maximilian Bremer <[e-mail]>

https://github.com/mozilla/pdf.js/commit/6d7157a875c75679c7b0d3d15454db2ca62fbd37
Authored: 2024-09-29 02:23:20 +0200
Committed: 2024-11-06 12:04:55 +0100

Fix Typo:XFATemplate class Para Styling paddingight => paddingRight

Files Modified:

• src/core/xfa/template.js

---

d59f9648a9f6435fcc7f9963a6d3c2ff92bda612 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/d59f9648a9f6435fcc7f9963a6d3c2ff92bda612
Authored: 2024-11-05 22:04:47 +0100
Committed: 2024-11-05 22:35:35 +0100

Simplify toRomanNumerals function

Files Modified:

• src/core/core_utils.js

---

824a619a2a42175843006040ac3d124087a92896 by Andrii Vitiv <[e-mail]>

https://github.com/mozilla/pdf.js/commit/824a619a2a42175843006040ac3d124087a92896
Authored: 2024-11-05 19:01:56 +0200
Committed: 2024-11-05 21:52:50 +0200

Fix error on empty response headers

Fixes https://github.com/mozilla/pdf.js/issues/18957

https://github.com/mozilla/pdf.js/pull/18682 introduced a regression that causes the following error:

Uncaught TypeError: Failed to construct 'Headers': Invalid name
    at PDFNetworkStreamFullRequestReader._onHeadersReceived (pdf.mjs:10214:29)
    at NetworkManager.onStateChange (pdf.mjs:10103:22)

The mentioned PR replaced a call to getResponseHeader() with getAllResponseHeaders() without handling cases where it may return null or an empty string. Quote from the docs:

Returns:

A string representing all of the response's headers (except those whose field name is Set-Cookie) separated by CRLF, or null if no response has been received. If a network error happened, an empty string is returned.

Run the following code and observe the error in the console. Note that the URL is intentionally set to an invalid value to simulate network error

<script src="//mozilla.github.io/pdf.js/build/pdf.mjs" type="module"></script>

<script type="module">
  var url = 'blob:';

  pdfjsLib.GlobalWorkerOptions.workerSrc = '//mozilla.github.io/pdf.js/build/pdf.worker.mjs';

  var loadingTask = pdfjsLib.getDocument(url);
  loadingTask.promise
    .then((pdf) => console.log('PDF loaded'))
    .catch((reason) => console.error(reason));

</script>

Files Modified:

• src/display/network.js

---

e92a929a5817a9b30531242beaa9ce2a1d37138f by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/e92a929a5817a9b30531242beaa9ce2a1d37138f
Authored: 2024-11-05 16:42:31 +0100
Committed: 2024-11-05 18:19:26 +0100

Try to improve handling of missing trailer dictionaries in XRef.indexObjects (issue 18986)

The problem with the referenced PDF document has nothing to do with invalid dates, as the issue seems to suggest, but rather with the fact that it has neither an XRef table nor a trailer dictionary.
Given that crucial parts of the internal document structure is missing, you might argue that it's not really a PDF document.

In an attempt to support this kind of corruption, we'll simply iterate through all (previously found) XRef entries and pick one that might be a valid /Root dictionary.
There's obviously no guarantee that this works, and it might not be fast in larger PDF documents, but at least it cannot be any worse than immediately throwing InvalidPDFException as we previously did here.

Please note: I'm totally fine with this patch being rejected, since it's somewhat questionable if we should actually attempt to support "PDF documents" with this level of corruption.

Files Added:

• test/pdfs/issue18986.pdf

Files Modified:

• src/core/xref.js
• test/pdfs/.gitignore
• test/test_manifest.json
• test/unit/api_spec.js

---

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

https://github.com/mozilla/pdf.js/commit/2c90eee5a877c6a71c844e836f17690f19c43b67
Authored: 2024-11-05 13:55:13 +0100
Committed: 2024-11-05 13:58:00 +0100

Shorten a few helper functions in src/core/core_utils.js

In a few cases we can ever so slightly shorten the code without negatively impacting the readability.

Files Modified:

• src/core/core_utils.js

---

f2fb3b95ce8daf58663a2c7209461932b0026345 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/f2fb3b95ce8daf58663a2c7209461932b0026345
Authored: 2024-11-04 14:09:34 +0100
Committed: 2024-11-04 14:09:34 +0100

Add helper functions to load image blob/bitmap data in test/unit/api_spec.js

This avoids repeating the same code multiple times, and as part of the changes we'll also utilize existing PDF.js helpers more.

Files Modified:

• test/unit/api_spec.js

---

e4a5bd95553e7d5c86f5b502d264e1c7a65cbac0 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/e4a5bd95553e7d5c86f5b502d264e1c7a65cbac0
Authored: 2024-11-04 10:37:35 +0100
Committed: 2024-11-04 10:37:35 +0100

Bump library version to 4.9

Files Modified:

• pdfjs.config

---

9269fb9be2d1a4230a510b4c1e8d6542b36b448d by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/9269fb9be2d1a4230a510b4c1e8d6542b36b448d
Authored: 2024-09-04 15:54:08 +0200
Committed: 2024-11-03 16:18:12 +0100

Remove the BaseFullReader and BaseRangeReader classes in the src/display/node_stream.js file

After the previous patch these base-classes are only extended once each and they can thus be combined with the final classes.

Files Modified:

• src/display/node_stream.js

---

cbf0ca71bf91ef0dca62b5736d43860107275117 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/cbf0ca71bf91ef0dca62b5736d43860107275117
Authored: 2024-09-04 13:58:54 +0200
Committed: 2024-11-03 16:18:10 +0100

[api-minor] Only support the Fetch API for "remote" PDF documents in Node.js environments

The Fetch API has been supported since Node.js version 18, see https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API#browser_compatibility

Files Modified:

• src/display/api.js
• src/display/node_stream.js
• test/unit/node_stream_spec.js

---

c7407230c191be42971e714ff5b2b1055c33e2a7 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/c7407230c191be42971e714ff5b2b1055c33e2a7
Authored: 2024-06-12 11:19:51 +0200
Committed: 2024-11-03 16:13:58 +0100

[api-minor] Load Node.js packages/polyfills with process.getBuiltinModule

This allows synchronous loading of Node.js modules and (indirectly) packages, thus simplifying the code a fair bit.

Files Modified:

• src/display/api.js
• src/display/node_stream.js
• src/display/node_utils.js
• src/display/stubs.js
• test/unit/clitests_helper.js
• test/unit/node_stream_spec.js
• test/unit/test_utils.js

---

4f01cdef184d02a8e5d265bb4cba6730add98515 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/4f01cdef184d02a8e5d265bb4cba6730add98515
Authored: 2024-10-20 13:40:59 +0200
Committed: 2024-11-03 16:13:55 +0100

[api-minor] Update the minimum supported Node.js version to 20

This patch updates the minimum supported environments as follows:

• Node.js 20, which was released on 2023-04-18 and has now entered the "Maintenance"-phase; see https://github.com/nodejs/release#release-schedule

Furthermore, note also that Node.js 18 will fairly soon reach EOL.

Files Modified:

• .github/workflows/ci.yml
• gulpfile.mjs
• package-lock.json
• package.json

---

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

https://github.com/mozilla/pdf.js/commit/3adf8b6be0252c89b5c7dea77ea61a63c839be30
Authored: 2024-11-03 15:00:35 +0100
Committed: 2024-11-03 15:08:55 +0100

Fix the "must convert input to uppercase" scripting integration test

This integration test fails intermittently because we're not
(correctly) awaiting the sandbox actions. The 27R field in
issue14862.pdf triggers sandbox events for every typing action, but
for the backspace and "a" character typing actions we weren't awaiting
the sandbox trip at all, and for other places we weren't awaiting it
fully (causing some characters to be missed in the assertion).

This commit fixes the issues by using the appropriate helper functions,
similar to what we did in PR #18399. Not only is this shorter in terms
of code, but it also fixed the near-permafail for this test with newer
versions of Puppeteer.

Files Modified:

• test/integration/scripting_spec.mjs

---

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

https://github.com/mozilla/pdf.js/commit/ccfaf20ee22c84845f1a173651e3730b7cac0e92
Authored: 2024-11-03 13:30:06 +0100
Committed: 2024-11-03 13:40:55 +0100

Install and use the most recent Node types for the types tests

The types tests run in Node.js and therefore use Node types for e.g.
builtins. However, we didn't explicitly indicate this in
tsconfig.json (see [1] for more information and [2] for the PR where
we found this). Moreover, we didn't explicitly install the most recent
version of @types/node which implicitly made us fall back to version
14.14.45 (because that was installed as a dependency of other modules)
whereas much newer versions are available and we need those after
changes in Node.js (see [3] for more information and [4] for the PR
where we found this).

This commit fixes both issues by explicitly installing and using the
most recent Node.js types, which should also avoid future issues with
the types tests.

[1] https://github.com/TypeStrong/ts-node/issues/1012
[2] https://github.com/mozilla/pdf.js/pull/18237
[3] https://stackoverflow.com/questions/78790943/in-typescript-5-6-buffer-is-not-assignable-to-arraybufferview-or-uint8arr
[4] https://github.com/mozilla/pdf.js/pull/18959

Files Modified:

• package-lock.json
• package.json
• test/types/tsconfig.json

---

f78a8f3c54efdd0ad5c1abd1683e6d3da590d712 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/f78a8f3c54efdd0ad5c1abd1683e6d3da590d712
Authored: 2024-11-03 11:25:19 +0100
Committed: 2024-11-03 11:25:19 +0100

Use the toBase64Util helper function in the unit-tests

Files Modified:

• test/unit/display_utils_spec.js

---

faf9e32ecb20c394bc7f4b485be1ad49e3bf3ad8 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/faf9e32ecb20c394bc7f4b485be1ad49e3bf3ad8
Authored: 2024-11-03 00:10:23 +0100
Committed: 2024-11-03 00:15:44 +0100

Enable the "should have an alt attribute from toolTip" unit-test in Node.js

Despite the pending-message mentioning "Image", this appears to be another case where the code actually depends on Blob; note https://github.com/mozilla/pdf.js/blob/cf3ca8b5bc95154712bcde96ee85a0bf7afacb2f/src/core/xfa/template.js#L3453

Files Modified:

• test/unit/xfa_tohtml_spec.js

---

15fbee158c06b0c82fc6d23a7c8ebd18ae1a07fc by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/15fbee158c06b0c82fc6d23a7c8ebd18ae1a07fc
Authored: 2024-11-02 23:47:58 +0100
Committed: 2024-11-02 23:53:03 +0100

Enable the 'gets PDF filename from query string appended to "blob:" URL' unit-test in Node.js

The necessary functionality has been supported in Node.js for quite some time now, please see:

• https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob#browser_compatibility
• https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static#browser_compatibility

Files Modified:

• test/unit/display_utils_spec.js

---

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

https://github.com/mozilla/pdf.js/commit/3854ab5efdccb6ebd8e8e1549138c49110b828b7
Authored: 2024-11-02 20:21:59 +0100
Committed: 2024-11-02 20:21:59 +0100

Update translations to the most recent versions

Files Modified:

• l10n/bg/viewer.ftl
• l10n/cs/viewer.ftl
• l10n/cy/viewer.ftl
• l10n/da/viewer.ftl
• l10n/dsb/viewer.ftl
• l10n/el/viewer.ftl
• l10n/en-GB/viewer.ftl
• l10n/es-AR/viewer.ftl
• l10n/es-CL/viewer.ftl
• l10n/fr/viewer.ftl
• l10n/fur/viewer.ftl
• l10n/fy-NL/viewer.ftl
• l10n/gn/viewer.ftl
• l10n/he/viewer.ftl
• l10n/hsb/viewer.ftl
• l10n/ia/viewer.ftl
• l10n/is/viewer.ftl
• l10n/it/viewer.ftl
• l10n/ko/viewer.ftl
• l10n/nl/viewer.ftl
• l10n/pt-BR/viewer.ftl
• l10n/ru/viewer.ftl
• l10n/si/viewer.ftl
• l10n/sk/viewer.ftl
• l10n/sq/viewer.ftl
• l10n/sv-SE/viewer.ftl
• l10n/vi/viewer.ftl
• l10n/zh-CN/viewer.ftl
• l10n/zh-TW/viewer.ftl

---

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

https://github.com/mozilla/pdf.js/commit/3cd906829ec94d2d845655fe18b1fbcd8cf510b3
Authored: 2024-11-02 20:17:17 +0100
Committed: 2024-11-02 20:20:58 +0100

Update dependencies to the most recent versions

Files Modified:

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

---

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

https://github.com/mozilla/pdf.js/commit/627a58833652b1097e5ac898fb78aceeaab5de9e
Authored: 2024-11-02 19:56:10 +0100
Committed: 2024-11-02 19:56:10 +0100

Bump the stable version in pdfjs.config

Files Modified:

• pdfjs.config

---

2145a7b9ca5343e7257f3595d697004b2a8fcfe0 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/2145a7b9ca5343e7257f3595d697004b2a8fcfe0
Authored: 2024-11-02 15:00:32 +0100
Committed: 2024-11-02 15:00:32 +0100

Use the hexNumbers structure in the stringToUTF16HexString helper

We can re-use the hexNumbers structure here, since that allows us to directly lookup the hexadecimal values and shortens the code.

Files Modified:

• src/core/core_utils.js
• src/shared/util.js

---

196f7d7df142db257e42c75a7bf87060d3aa5065 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/196f7d7df142db257e42c75a7bf87060d3aa5065
Authored: 2024-11-02 11:06:30 +0100
Committed: 2024-11-02 11:06:30 +0100

Inline the flushChunks helper function, used in getPdfManager on the worker-thread

• This helper function has only a single call-site, and the function is fairly short.

• It'll only be invoked if range requests are disabled, or if the entire PDF manages to load before the headers are resolved (which is very unlikely).
  Hence, by default, this helper function is not invoked.

• By inlining the code we're able to utilize the existing error-handling at the call-site, rather than having to duplicate it, which further reduces the size of this code.

Finally, while slightly unrelated, this patch also adds optional chaining in one spot in the file (PR 16424 follow-up).

Files Modified:

• src/core/worker.js

---

b26dc1939207ac16acc3a2ffbb768ee37becdd0c by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b26dc1939207ac16acc3a2ffbb768ee37becdd0c
Authored: 2024-11-01 17:22:46 +0100
Committed: 2024-11-01 17:43:59 +0100

Ensure that serializing of StructTree-data cannot fail during loading

I discovered that doing skip-cache re-reloading of https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf would intermittently cause (some of) the AnnotationLayers to break with errors printed in the console (see below).

In hindsight this bug is really obvious, however it took me quite some time to find it, since the StructTreePage.prototype.serializable getter will lookup various data and all of those cases can fail during loading when streaming and/or range requests are being used.

Finally, to prevent any future errors, ensure that the viewer won't break in these sort of situations.

Uncaught (in promise)
Object { message: "Missing data [19098296, 19098297)", name: "UnknownErrorException", details: "MissingDataException: Missing data [19098296, 19098297)", stack: "BaseExceptionClosure@resource://pdf.js/build/pdf.mjs:453:29\n@resource://pdf.js/build/pdf.mjs:456:2\n" }
viewer.mjs:8801:55

\#renderAnnotationLayer: "UnknownErrorException: Missing data [17552729, 17552730)". viewer.mjs:8737:15

Uncaught (in promise)
Object { message: "Missing data [17552729, 17552730)", name: "UnknownErrorException", details: "MissingDataException: Missing data [17552729, 17552730)", stack: "BaseExceptionClosure@resource://pdf.js/build/pdf.mjs:453:29\n@resource://pdf.js/build/pdf.mjs:456:2\n" }
viewer.mjs:8801:55

Files Modified:

• src/core/document.js
• web/struct_tree_layer_builder.js

---

4e12906061a3a6022d542936ba927931c494f33d by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/4e12906061a3a6022d542936ba927931c494f33d
Authored: 2024-11-01 12:34:39 +0100
Committed: 2024-11-01 13:31:28 +0100

Move the various DOM-factories into their own files

• Over time the number and size of these factories have increased, especially the DOMFilterFactory class, and this split should thus aid readability/maintainability of the code.

• By introducing a couple of new import maps we can avoid bundling the DOMCMapReaderFactory/DOMStandardFontDataFactory classes in the Firefox PDF Viewer, since they are dead code there given that worker-thread fetching is always being used.

• This patch has been successfully tested, by running $ ./mach test toolkit/components/pdfjs/, in a local Firefox artifact-build.

Note: This patch reduces the size of the gulp mozcentral output by 1.3 kilo-bytes, which isn't a lot but still cannot hurt.

Files Added:

• src/display/canvas_factory.js
• src/display/cmap_reader_factory.js
• src/display/filter_factory.js
• src/display/standard_fontdata_factory.js
• src/display/svg_factory.js
• test/unit/canvas_factory_spec.js
• test/unit/svg_factory_spec.js

Files Deleted:

• src/display/base_factory.js

Files Modified:

• gulpfile.mjs
• src/display/annotation_layer.js
• src/display/api.js
• src/display/display_utils.js
• src/display/draw_layer.js
• src/display/node_utils.js
• src/display/stubs.js
• src/pdf.js
• test/unit/clitests.json
• test/unit/display_utils_spec.js
• test/unit/jasmine-boot.js
• test/unit/pdf_spec.js
• test/unit/unit_test.html
• tsconfig.json
• web/viewer-geckoview.html
• web/viewer.html

---

7572382c7ac1df33fc3ffbc2d0666387bb08cc11 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/7572382c7ac1df33fc3ffbc2d0666387bb08cc11
Authored: 2024-10-31 09:25:07 +0100
Committed: 2024-10-31 09:29:11 +0100

Change the "FetchBuiltInCMap"/"FetchStandardFontData" message-handlers to be asynchronous

This way we can directly throw Errors, rather than having to "manually" return rejected Promises, which is ever so slightly shorter.

Also, since useWorkerFetch is always true in MOZCENTRAL builds these message-handlers should not be invoked there.

Files Modified:

• src/display/api.js

---

cdd4b052f984970e17be81ed24986f09d25e80f3 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/cdd4b052f984970e17be81ed24986f09d25e80f3
Authored: 2024-10-30 15:20:44 +0100
Committed: 2024-10-30 15:20:44 +0100

Don't initialize L10n.#elements eagerly since it's unused in MOZCENTRAL builds

It's not necessary to manually start translation in the Firefox PDF Viewer, and doing so would even cause problems there (see issue 17142).

Files Modified:

• web/l10n.js

---

db1238aae3de5b6d7da62598a2f4f0c1dca2d3fa by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/db1238aae3de5b6d7da62598a2f4f0c1dca2d3fa
Authored: 2024-10-29 16:35:44 +0100
Committed: 2024-10-29 16:35:44 +0100

Re-factor the toHexUtil helper (PR 17862 follow-up)

We can re-use the hexNumbers structure, since that allows us to directly lookup the hexadecimal values and shortens the code.

Files Modified:

• src/shared/util.js

---

5a9607b2adda2cc55a75ee63b69aa99938bd7e3b by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/5a9607b2adda2cc55a75ee63b69aa99938bd7e3b
Authored: 2024-10-28 20:29:50 +0100
Committed: 2024-10-29 15:41:08 +0100

[Editor] Refactor the free highlight stuff in order to be able to use the code for more general drawing

One goal is to make the code for drawing with the Ink tool similar to the one to free highlighting:
it doesn't really make sense to have so different ways to do almost the same thing.

When the zoom level is high, it'll avoid to create a too big canvas covering all the page which consume
more memory, makes the drawing very slow and the overall user xp pretty bad.

A second goal is to be able to easily implement more drawing tools where we would just have to implement
how to draw from the pointer coordinates.

Files Added:

• src/display/editor/drawers/highlight.js
• src/display/editor/drawers/outline.js

Files Modified:

• src/display/draw_layer.js
• src/display/editor/highlight.js
• src/pdf.js
• test/driver.js

Files Changed:

• R056 src/display/editor/outliner.js

---

afb4813d1c4288011c93383d28c4445e9af28596 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/afb4813d1c4288011c93383d28c4445e9af28596
Authored: 2024-10-29 13:21:25 +0100
Committed: 2024-10-29 14:59:39 +0100

Simplify the "ReaderHeadersReady" message-handler in the API

We can convert the handler to an async function, which removes the need to create a temporary Promise here.
Given the age of this code it shouldn't hurt to simplify it a little bit.

Files Modified:

• src/display/api.js

---

8f47d06d075f6c803f43f22fee8bdc3930c33b17 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/8f47d06d075f6c803f43f22fee8bdc3930c33b17
Authored: 2024-10-14 14:26:11 +0200
Committed: 2024-10-29 10:22:35 +0100

Add helper functions to allow using new Uint8Array methods

This allows using the new methods in browsers that support them, e.g. Firefox 133+, while still providing fallbacks where necessary; see https://github.com/tc39/proposal-arraybuffer-base64

Please note: These are not actual polyfills, but only implements what we need in the PDF.js code-base. Eventually this patch should be reverted, once support is generally available.

Files Modified:

• src/core/document.js
• src/core/xfa/template.js
• src/display/font_loader.js
• src/shared/util.js

---

bfc645bab17c0544aee1466513200dfd396f2579 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/bfc645bab17c0544aee1466513200dfd396f2579
Authored: 2024-04-10 12:45:22 +0200
Committed: 2024-10-29 10:22:35 +0100

Introduce some Uint8Array.fromBase64 and Uint8Array.prototype.toBase64 usage in the main code-base

See https://github.com/tc39/proposal-arraybuffer-base64

Files Modified:

• src/core/xfa/template.js
• src/display/font_loader.js

---

f9fc4770804edfc404def28335cf8ad04e2e724e by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/f9fc4770804edfc404def28335cf8ad04e2e724e
Authored: 2024-03-31 12:43:07 +0200
Committed: 2024-10-29 10:22:35 +0100

Improve the implementation of the PDFDocument.fingerprints-getter

• Add explicit length validation of the /ID entries. Given the EMPTY_FINGERPRINT constant we're already implicitly assuming a particular length.

• Move the constants into the fingerprints-getter, since they're not used anywhere else.

• Replace the hexString helper function with the standard Uint8Array.prototype.toHex method; see https://github.com/tc39/proposal-arraybuffer-base64

Files Modified:

• src/core/document.js

---

48a18585f299dbad1e80b0e761bfbdcbbcf7958e by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/48a18585f299dbad1e80b0e761bfbdcbbcf7958e
Authored: 2024-10-29 08:52:14 +0100
Committed: 2024-10-29 09:36:08 +0100

Allow StreamsSequenceStream to skip sub-streams that are not actual Streams (issue 18973)

This extends PR 13796 to also handle the case where sub-streams contain invalid data, i.e. anything that isn't a Stream, however please note that in these cases there's no guarantee that we'll render the page "correctly".

Note that Adobe Reader, i.e. the PDF reference implementation, cannot render the last page of the referenced PDF document.

Files Added:

• test/pdfs/issue18973.pdf.link

Files Modified:

• src/core/decode_stream.js
• test/test_manifest.json

---

ee812b5df2a984b00c0ff398bdd66e54fea3925f by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/ee812b5df2a984b00c0ff398bdd66e54fea3925f
Authored: 2024-10-28 14:34:12 +0100
Committed: 2024-10-28 17:19:02 +0100

[Editor] Utilize Fluent "better" when localizing the AltText

Currently we manually localize and update the DOM-elements of the AltText-button, and it seems nicer to utilize Fluent "properly" for that task.
This can be achieved by introducing an explicit span-element on the AltText-button (similar to e.g. the regular toolbar-buttons), and adding a few more l10n-strings, since that allows just setting the data-l10n-id-attribute on all the relevant DOM-elements.

Finally, note how we no longer need to localize any strings eagerly when initializing the various editors.

Files Modified:

• l10n/en-US/viewer.ftl
• src/display/editor/alt_text.js
• src/display/editor/editor.js
• test/integration/stamp_editor_spec.mjs

---

b649b6f8dd4eaf7a7ee036ff9985d0918556991c by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b649b6f8dd4eaf7a7ee036ff9985d0918556991c
Authored: 2024-10-18 17:23:48 +0200
Committed: 2024-10-28 14:09:52 +0100

Use a BMP decoder when resizing an image

The image decoding won't block the main thread any more.
For now, it isn't enabled for Chrome because issue6741.pdf leads to a crash.

Files Modified:

• src/core/evaluator.js
• src/core/image_resizer.js
• src/display/api.js

---

8fbb9e2f169ed7b2ec6de614e976c6550696db39 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/8fbb9e2f169ed7b2ec6de614e976c6550696db39
Authored: 2024-10-27 20:24:24 +0100
Committed: 2024-10-28 11:08:30 +0100

[Editor] Split the long words when showing the alt-text tooltip (bug 1903588)

Files Modified:

• test/integration/stamp_editor_spec.mjs
• web/annotation_editor_layer_builder.css

---

230d7f92291d2aa3b7b7493d419667b625d0513c by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/230d7f92291d2aa3b7b7493d419667b625d0513c
Authored: 2024-10-27 19:19:06 +0100
Committed: 2024-10-27 19:19:06 +0100

Make util.scand a bit more flexible with dates which don't match the given format (bug 1910431)

Files Modified:

• src/scripting_api/aform.js
• src/scripting_api/util.js
• test/unit/scripting_spec.js

---

8a2b95418a6293a9fc3002bce0a4557c4822afda by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/8a2b95418a6293a9fc3002bce0a4557c4822afda
Authored: 2024-10-27 11:03:04 +0100
Committed: 2024-10-27 11:03:04 +0100

Re-factor the ImageResizer._goodSquareLength definition

Move the ImageResizer._goodSquareLength definition into the class itself, since the current position shouldn't be necessary, and also convert it into an actually private field.

Files Modified:

• src/core/image_resizer.js

---

d114f71feb7051f922fe02a02b81b34aeba2a631 by Calixte Denizet <[e-mail]>

https://github.com/mozilla/pdf.js/commit/d114f71feb7051f922fe02a02b81b34aeba2a631
Authored: 2024-10-26 14:14:44 +0200
Committed: 2024-10-26 14:14:51 +0200

Always fill the mask with the backdrop color

It fixes #18956.

In the patch #18029, for performance reasons and because I thought it was useless, I deliberately chose to not fill the mask
with the backdrop color when it's full black: it was a bad idea.
So in this patch we always add the backdrop color to the mask.

Files Added:

• test/pdfs/issue18956.pdf

Files Modified:

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

---

b048420d21b2352bded393e81254648ce6998e6c by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/b048420d21b2352bded393e81254648ce6998e6c
Authored: 2024-10-23 15:35:00 +0200
Committed: 2024-10-24 11:08:16 +0200

[api-minor] Remove the CMapCompressionType enumeration

After the binary CMap format had been added there were also some ideas about maybe providing other formats, see here, however that was over seven years ago and we still only use binary CMaps.
Hence it now seems reasonable to simplify the relevant code by removing CMapCompressionType and instead just use a boolean to indicate the type of the built-in CMaps.

Files Modified:

• src/core/cmap.js
• src/core/evaluator.js
• src/display/base_factory.js
• src/pdf.js
• src/shared/util.js
• test/unit/pdf_spec.js
• web/pdfjs.js

---

50c291eb33d8553b63c130779a4edfeac98d85e8 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/50c291eb33d8553b63c130779a4edfeac98d85e8
Authored: 2024-10-23 12:03:12 +0200
Committed: 2024-10-24 10:15:09 +0200

Unconditionally cache built-in CMaps on the worker-thread

Given that we've not shipped, nor used, anything except binary CMaps for years let's just cache them unconditionally (since that's a tiny bit less code).

Files Modified:

• src/core/evaluator.js

---

Comment 2

[Update Bot]

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

Comment 3

[Update Bot]

Attachment: Bug 1929709 - Update PDF.js to bff673896614b4b8c30f28397471cb89922a9a31

Comment 4

[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.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af9b668bb659
Update PDF.js to bff673896614b4b8c30f28397471cb89922a9a31 r=pdfjs-reviewers,marco

Comment 6

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/af9b668bb659