1811712 - Update PDF.js to new version edfdb693e5b11057252f8cef9388d063678d95cd from 2023-01-21 13:02:40

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

This update covers 23 commits:

---

d7013bee54f4b6f3ff174c3381062d1e2474eb62 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/d7013bee54f4b6f3ff174c3381062d1e2474eb62
Authored: 2023-01-21 12:29:36 +0100
Committed: 2023-01-21 12:32:34 +0100

Move the disableAutoFetch functionality into the ProgressBar-class

It seems nicer overall, since we're exporting the ProgressBar in the viewer-components, to move this functionality into the ProgressBar-class itself rather than handling it "manually" in the default-viewer.

Files Modified:

• web/app.js
• web/ui_utils.js

---

40a46e4397798bca90495830275d5a3ae1468497 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/40a46e4397798bca90495830275d5a3ae1468497
Authored: 2023-01-21 12:00:17 +0100
Committed: 2023-01-21 12:21:21 +0100

Tweak adjustType1ToUnicode for fonts with a predefined named encoding (bug 1811668, PR 14050 follow-up)

Please note: I cannot reproduce the problem reported in bug 1811668, regarding the context menu, and in any case it's not clear that that part is even a PDF Viewer bug.

Looking at bug 1811668 I couldn't help but noticing that the textLayer isn't correct, and it's unfortunately once again a problem with the adjustType1ToUnicode function. That's intended to help improve text-selection for fonts without a /ToUnicode-entry, and in many cases it does help (the original PR fixed lots of issues) however it's also caused some problems.

In order to improve text-selection in bug 1811668, we'll now properly ignore fonts that have a predefined named encoding specified since that's really the intention with PR 14050.

Files Added:

• test/pdfs/bug1811668_reduced.pdf

Files Modified:

• src/core/fonts.js
• test/pdfs/.gitignore
• test/test_manifest.json

---

dc94b750de030649675b8ae5975ab6d3202ab16f by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/dc94b750de030649675b8ae5975ab6d3202ab16f
Authored: 2023-01-20 15:40:33 +0100
Committed: 2023-01-20 18:13:16 +0100

[GV] Avoid to update the finder when the results aren't complete

At the beginning of a search we can an update can be triggered with 0 over 0
found matches.
In the GeckoView context, we can't update the finder whenever we want but only
when it has been required.

Files Modified:

• test/unit/pdf_find_controller_spec.js
• web/pdf_find_controller.js

---

f2fce93826ff2e7a94b948cd7961f1ae3f8bc784 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/f2fce93826ff2e7a94b948cd7961f1ae3f8bc784
Authored: 2023-01-19 17:08:13 +0100
Committed: 2023-01-19 17:14:17 +0100

[JBIG2] Ensure that the decodeInteger function returns valid integers (issue 15942)

The JBIG2 images in this PDF document are corrupt enough that even Adobe Reader warns about it when opening the file.
Please note: I don't really know the JBIG2 image format at all, however from a very brief look at the specification it seems that integers should be 32-bit.

Files Added:

• test/pdfs/issue15942.pdf.link

Files Modified:

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

---

7976fc7851a486cc04f2f393ed5e15981366e9ab by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/7976fc7851a486cc04f2f393ed5e15981366e9ab
Authored: 2023-01-19 12:40:09 +0100
Committed: 2023-01-19 14:25:55 +0100

[api-minor] Deprecate calling getDocument directly with a PDFDataRangeTransport-instance

In general it's recommended to pass a parameter object when calling the getDocument-function in the API, since that's the only way to provide additional options, and the fact that it also accepts a URL or TypedArray directly is now mostly for backwards compatibility reasons.
However, the getDocument-function also accepts a direct PDFDataRangeTransport-instance which just seems unnecessary.

Please note: The PDFDataRangeTransport-implementation was added specifically for the built-in Firefox PDF Viewer, however it's most likely not commonly used by any third-party (given that it requires manual PDF-data loading).
Furthermore, the default-viewer always provides a parameter object when calling the getDocument-function and it's thus completely unaffected by these changes.

Files Modified:

• src/display/api.js
• test/unit/api_spec.js

---

eee65e4b6e99f422fb444204dc8020d439d73f7d by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/eee65e4b6e99f422fb444204dc8020d439d73f7d
Authored: 2023-01-17 17:57:55 +0100
Committed: 2023-01-19 13:35:35 +0100

Add a PDFViewerApplication helper method to center the position after wheel/pinch-zooming

This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.

Files Modified:

• web/app.js

---

31ae3a4ba0f8eb61e8b79e933175891b964583e2 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/31ae3a4ba0f8eb61e8b79e933175891b964583e2
Authored: 2023-01-19 09:54:20 +0100
Committed: 2023-01-19 09:54:25 +0100

Change 'Current View' to 'Current Page' in the secondary toolbar

Content Design team (UX) proposed this change.

Files Modified:

• l10n/en-US/viewer.properties
• web/viewer.html

---

7b36686fcaa09d4db2625e8a508d7cf5ab8a55c4 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/7b36686fcaa09d4db2625e8a508d7cf5ab8a55c4
Authored: 2023-01-18 22:28:18 +0100
Committed: 2023-01-18 22:28:18 +0100

Update the year in the license_header files

Files Modified:

• src/license_header.js
• src/license_header_libre.js

---

4b5817f8ffe33feccde2b7e068e2838f193b1484 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/4b5817f8ffe33feccde2b7e068e2838f193b1484
Authored: 2023-01-18 10:49:52 +0100
Committed: 2023-01-18 10:49:52 +0100

Use consistent forced-colors media-queries throughout the CSS files

Note how e.g. the viewer.css and pdf_viewer.css files already used this format.

Files Modified:

• web/annotation_editor_layer_builder.css
• web/annotation_layer_builder.css
• web/text_layer_builder.css
• web/xfa_layer_builder.css

---

67b1d153847bffe5e0e1364e5fff5f9ab56c273b by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/67b1d153847bffe5e0e1364e5fff5f9ab56c273b
Authored: 2023-01-18 10:42:22 +0100
Committed: 2023-01-18 10:42:22 +0100

Use CSS variables for the textLayer highlight colors (PR 15921 follow-up)

Rather than adding @media (forced-colors: active) { ... }-blocks throughout the CSS code, we should utilize CSS variables instead as in our other CSS files.

Files Modified:

• web/text_layer_builder.css

---

d6be5141e9b4332e43f045544ea3716929fea3fa by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/d6be5141e9b4332e43f045544ea3716929fea3fa
Authored: 2023-01-17 15:26:58 +0100
Committed: 2023-01-17 16:04:51 +0100

Fallback to using the name table to infer the encoding for TrueType fonts missing such data (issue 15910)

The relevant TrueType font is missing both /ToUnicode and /Encoding entires, either of which would have prevented the (current) broken textLayer rendering.
My first idea was that we could use the post table in the TrueType font, see https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html, to get the actual glyphNames and amend the fallback ToUnicode-map that way. Unfortunately that didn't work, since the post table only contained ".notdef" and "" (i.e. empty string) entries.

Instead we try to use the name table in the TrueType font, see https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6name.html, to determine if the platform is Windows and thus fallback to generate a ToUnicode-map from the WinAnsiEncoding.

Files Added:

• test/pdfs/issue15910.pdf

Files Modified:

• src/core/fonts.js
• test/pdfs/.gitignore
• test/test_manifest.json

---

089ed6fb6522257017741d5737ac205bc745b565 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/089ed6fb6522257017741d5737ac205bc745b565
Authored: 2023-01-16 19:38:33 +0100
Committed: 2023-01-17 10:50:53 +0100

Move --scale-factor variable in the viewer container (fix #15929)

When a css variable is update in a node then all the children under this
node are updated.
In order to avoid to update all the UI when a page is rescaling, this
patch moves the --scale-factor from the :root to the viewer container.

Files Modified:

• web/pdf_page_view.js
• web/pdf_viewer.css
• web/pdf_viewer.js

---

cefaecc2e8df1dff20ce3beb6ede9ef16dcdac28 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/cefaecc2e8df1dff20ce3beb6ede9ef16dcdac28
Authored: 2023-01-16 12:56:43 +0100
Committed: 2023-01-16 13:02:53 +0100

Ensure that Annotation appearance-entries are actually Streams

Note how all over the src/core/annotation.js-code we're assuming that if an appearance-entry exists it's also a Stream. However, we're not actually checking that thoroughly enough which causes issues in some badly generated PDF documents.

Files Added:

• test/pdfs/checkbox-bad-appearance.pdf

Files Modified:

• src/core/annotation.js
• test/pdfs/.gitignore
• test/test_manifest.json

---

32357e3d172a552e0408b3e1ed743e87fe7d5a21 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/32357e3d172a552e0408b3e1ed743e87fe7d5a21
Authored: 2023-01-15 11:37:53 +0100
Committed: 2023-01-15 15:38:30 +0100

Update rimraf to version 4

The primary change is that the rimraf function now returns a Promise instead of taking a callback; please see https://github.com/isaacs/rimraf#major-changes-from-v3-to-v4

Files Modified:

• gulpfile.js
• package-lock.json
• package.json
• test/test.js
• test/testutils.js

---

cbf9843a79378b600a36a3f5d1f2c6b72148ff84 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/cbf9843a79378b600a36a3f5d1f2c6b72148ff84
Authored: 2023-01-15 10:43:46 +0100
Committed: 2023-01-15 10:43:46 +0100

Update l10n files

Files Added:

• l10n/skr/viewer.properties

Files Modified:

• l10n/be/viewer.properties
• l10n/fur/viewer.properties
• l10n/pt-BR/viewer.properties

---

d527bd0d92790d1edc44062a8ca712e6af9db949 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/d527bd0d92790d1edc44062a8ca712e6af9db949
Authored: 2023-01-15 10:34:56 +0100
Committed: 2023-01-15 10:34:56 +0100

Update npm packages

Files Modified:

• package-lock.json
• package.json

---

906745de38d3b552e28910c9ce4ab88ef7f43ee5 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/906745de38d3b552e28910c9ce4ab88ef7f43ee5
Authored: 2023-01-14 23:15:15 +0100
Committed: 2023-01-14 23:25:04 +0100

[Regression] Avoid showing a black canvas during zooming with a drawingDelay set (PR 15812 follow-up)

After the changes in PR 15812 we'll now intermittently display completely black canvases during zooming. To reproduce this, try switching to wrapped-scrolling and zoom in/out very quickly using either the mouse-wheel or pinching.

Files Modified:

• web/pdf_page_view.js

---

9e3adb5ec70f62ecc9dd7c2b3cb15a02286b3d45 by Tim van der Meij

https://github.com/mozilla/pdf.js/commit/9e3adb5ec70f62ecc9dd7c2b3cb15a02286b3d45
Authored: 2023-01-08 14:49:20 +0100
Committed: 2023-01-14 15:09:58 +0100

Implement unit tests for the numberToString utility function

Files Modified:

• test/unit/core_utils_spec.js

---

a6dfcc89fab6a82000b3bf07a851a1b913190fc5 by Tim van der Meij

https://github.com/mozilla/pdf.js/commit/a6dfcc89fab6a82000b3bf07a851a1b913190fc5
Authored: 2023-01-08 14:43:07 +0100
Committed: 2023-01-14 15:09:58 +0100

Implement unit tests for the recoverJsURL utility function

Files Modified:

• test/unit/core_utils_spec.js

---

397f943ca327dadade6af2eb58685331d3c03065 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/397f943ca327dadade6af2eb58685331d3c03065
Authored: 2023-01-13 11:16:28 +0100
Committed: 2023-01-14 10:39:36 +0100

[api-minor] Enable transferring of TypedArray PDF data by default (PR 15908 follow-up)

This patch removes the recently introduced transferPdfData API-option, and simply enables transferring of TypedArray data by default instead of copying it. This will help reduce main-thread memory usage, however it will take ownership of the TypedArrays. Currently this only applies to the following cases:

• TypedArrays passed to the getDocument-function in the API, in order to open PDF documents from binary data.
• TypedArrays passed to a PDFDataRangeTransport-instance, used to support custom PDF document fetching/loading (see e.g. the Firefox PDF Viewer).

PLEASE NOTE: To avoid being affected by this, please simply copy any TypedArray data before passing it to either of the functions/methods mentioned above.

Now that we transfer TypedArray data that we previously only copied, we need to be more careful with input validation. Given how the {IPDFStreamReader, IPDFStreamRangeReader}.read methods will always return ArrayBuffer data, which is then transferred to the worker-thread[1], the actual TypedArray data passed to the API thus need to have the same exact size as its underlying ArrayBuffer to prevent issues.
Hence we'll check for this and only allow transferring of safe TypedArray data, and fallback to simply copying the data just as before. This obviously shouldn't be an issue in the Firefox PDF Viewer, but for the general PDF.js library we need to be more careful here.

---

[1] See https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2492-L2506 respectively https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2578-L2590

Files Modified:

• src/display/api.js
• src/display/transport_stream.js
• test/unit/api_spec.js
• web/app_options.js

---

0a6b1cd2e9c548a8ac66aeffaebebcdc831653c3 by Fred Chasen

https://github.com/mozilla/pdf.js/commit/0a6b1cd2e9c548a8ac66aeffaebebcdc831653c3
Authored: 2023-01-12 13:56:34 -0800
Committed: 2023-01-13 14:35:12 -0800

Update highlight background color for forced colors

Files Modified:

• web/text_layer_builder.css

---

99cfab18c10a77f4c2f5fe17eb719ea67df82e61 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/99cfab18c10a77f4c2f5fe17eb719ea67df82e61
Authored: 2023-01-13 11:16:19 +0100
Committed: 2023-01-13 13:28:44 +0100

Combine the array-like and ArrayBuffer branches, when handling binary data, in getDocument

Files Modified:

• src/display/api.js

---

cee97fcd15cda22953f1eacf42f82a0039f362b7 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/cee97fcd15cda22953f1eacf42f82a0039f362b7
Authored: 2023-01-11 22:03:36 +0100
Committed: 2023-01-12 13:59:21 +0100

[api-minor] Enabling transferring of data fetched with the PDFFetchStream implementation

Note how in the API we're transferring the PDF data that's fetched over the network[1]:

• https://github.com/mozilla/pdf.js/blob/f28bf23a314e36d9e255037f5716ae1eb8e16fbf/src/display/api.js#L2467-L2480
• https://github.com/mozilla/pdf.js/blob/f28bf23a314e36d9e255037f5716ae1eb8e16fbf/src/display/api.js#L2553-L2564

To support that functionality we have the PDFDataTransportStream, PDFFetchStream, PDFNetworkStream, and PDFNodeStream implementations. Here these stream-implementations vary slightly in how they handle ArrayBuffers internally, w.r.t. transferring or copying the data:

• In PDFDataTransportStream we optionally, after PR 15908, allow transferring of the PDF data as provided externally (used e.g. in the Firefox PDF Viewer).
• In PDFFetchStream we're currenly always copying the PDF data returned by the Fetch API, which seems unnecessary. As discussed in PR 15908, it'd seem very weird if this sort of browser API didn't allow transferring of the returned data.
• In PDFNetworkStream we're already, since many years, transferring the PDF data returned by the XMLHttpRequest functionality. Note how the getArrayBuffer helper function simply returns an ArrayBuffer response as-is.
• In PDFNodeStream we're currently copying the PDF data, however this is unfortunately necessary since Node.js returns data as a Buffer object[2].

Given that the PDFNetworkStream has been, indirectly, supporting transferring of PDF data for years it would seem really strange if this didn't also apply to the PDFFetchStream-implementation.
Hence this patch simply enables transferring of PDF data, when accessed using the Fetch API, unconditionally to help reduced main-thread memory usage since the PDFFetchStream-implementation is used by default in browsers (for the GENERIC build).

---

[1] As opposed to PDF data being provided as e.g. a TypedArray when calling getDocument in the API.

[2] This is a "special" Node.js object, see https://nodejs.org/api/buffer.html#buffer, which doesn't exist in browsers.

Files Modified:

• src/display/api.js
• src/display/fetch_stream.js
• src/display/network.js

---

Comment 2

[Update Bot]

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

Comment 3

[Update Bot]

Attachment: Bug 1811712 - Update PDF.js to edfdb693e5b11057252f8cef9388d063678d95cd

Comment 4

[Update Bot]

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

Needs Investigation (From Push Health):

No tests were found for flavor 'plain' and the following manifest filters:

skip_if, run_if, fail_if, subsuite(name=None), tags(['condprof']), pathprefix(['toolkit/components/pdfjs/test'])

Make sure the test paths (if any) are spelt correctly and the corresponding
--flavor and --subsuite are being used. See mach mochitest --help for a
list of valid flavors.
- 2 of 2 failed on different tasks
- test-linux1804-64-qr/opt-mochitest-plain-condprof-1 (RtSd0LFxSAWKWu7ZiTbDDQ)
- test-windows10-64-2004-qr/opt-mochitest-plain-condprof-1 (EjYtSp9eRZGBV5djN8tEiA)

Needs Investigation (Other Failed Jobs):
test-macosx1015-64-qr/debug-mochitest-devtools-chrome-1
- 4 of 4 failed on the same (retriggered) task (c1QFXqmwSzuB5253pM01mw, Sb9hZLcvTL-48yB9zAE3Iw, fVt_w2kzQYC6xnUatEWPcQ, GiAGoJMaSBa2D_8wYOE0bg)
test-macosx1015-64-qr/debug-mochitest-devtools-chrome-spi-nw-1
- 4 of 4 failed on the same (retriggered) task (QjgZ2BLIRlurCdCZzbAzig, XOis6THQSyKel_UCdYWDGQ, WxmtEll_QBuMFB4le2e6Ww, MDbokJuMTZqQjwfF-m7g_Q)
test-windows10-64-2004-qr/debug-mochitest-devtools-chrome-1
- 4 of 4 failed on the same (retriggered) task (EFEOMX9RTyK60FiN2BxuRQ, aCPu6afVT-y8l3AKpUZGJw, FSoGqjd6RceBG5PxS3CE5Q, Ka9TejXDRZeHbMh4mr_8Bg)
test-linux1804-64-qr/debug-mochitest-devtools-chrome-swr-1
- 4 of 4 failed on the same (retriggered) task (AjFxUF43REm0xWAzLpYrLA, MYjsIDDdTpeXoGZS_DE5HA, Dt-Z1QK9TdymOCCcjx23OQ, CikCaH4OTya47M9CG1s68A)
test-linux1804-64-qr/debug-mochitest-devtools-chrome-1
- 4 of 4 failed on the same (retriggered) task (aCbqLLrPSYSLmx1ObQWNQQ, VC6LD2g6QliZU3iKKSu5rw, QTwfNCfhTfOqt3nBy5u7hQ, TPmZo0KSTu-5bJEw1uYrXw)
test-linux1804-64-qr/debug-mochitest-devtools-chrome-spi-nw-1
- 4 of 4 failed on the same (retriggered) task (OF7N6173QfyREmSjDeoLpQ, GmomundsRoCsH3crenyWBA, DwU8PunqSFeRdyt0SPpTIg, dP_6VC26QF-GRHgTqYpfqQ)
test-windows10-64-2004-qr/debug-mochitest-devtools-chrome-spi-nw-1
- 4 of 4 failed on the same (retriggered) task (MDZbxNTfTxO2Tbj7FP1d9g, fL-FgfVdQ3-H17kD46bIUA, fD-h3vchSgurKiyYsEgtIA, c-v7w3SST8abWggFi8JfKg)

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 5

[Pulsebot]

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

Comment 6

[Norisz Fay [:noriszfay]]

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