1853478 - Update PDF.js to new version 586d3add465fa9179c85a8fd5f10b874707a22eb from 2023-09-15 12:06:51

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

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

---

toolkit/components/pdfjs/content/build/pdf.js | 86 +++-
toolkit/components/pdfjs/content/build/pdf.scripting.js | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.js | 291 ++++++++-----
toolkit/components/pdfjs/content/web/viewer-geckoview.css | 81 ++-
toolkit/components/pdfjs/content/web/viewer-geckoview.js | 6 +-
toolkit/components/pdfjs/content/web/viewer.css | 81 ++-
toolkit/components/pdfjs/content/web/viewer.js | 6 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
8 files changed, 348 insertions(+), 211 deletions(-)

---

628ca737ddea46dbbe1536e2de1ffa6ba31f795b by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/628ca737ddea46dbbe1536e2de1ffa6ba31f795b
Authored: 2023-09-15 11:58:47 +0200
Committed: 2023-09-15 12:23:06 +0200

Make it possible to clear the cache, used by the getB function in src/core/pattern.js

While this cache will not contain a huge amount of data in practice, it's nonetheless a global cache that currently will never be cleared.

This patch also removes the existing closure, since it shouldn't really be necessary nowadays given that the code is a JavaScript module which means that only explicitly listed properties will be exported.

Files Modified:

• src/core/cleanup_helper.js
• src/core/pattern.js

---

93ce7c5a895b1ab499087d129fd228f07fc6a4e3 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/93ce7c5a895b1ab499087d129fd228f07fc6a4e3
Authored: 2023-09-15 11:46:00 +0200
Committed: 2023-09-15 11:46:00 +0200

Change the getB function, in src/core/pattern.js, to use the exponentiation operator

Files Modified:

• src/core/pattern.js

---

38f60a7effcd23b6bc7c6d7c8ab2025300b9c7b2 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/38f60a7effcd23b6bc7c6d7c8ab2025300b9c7b2
Authored: 2023-09-15 10:29:49 +0200
Committed: 2023-09-15 10:29:49 +0200

[Editor] Change the colors of the outline and the resizers for selected editors in HCM

Files Modified:

• web/annotation_editor_layer_builder.css

---

01f9f385d7e0e71aa065097154274bcea33608b6 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/01f9f385d7e0e71aa065097154274bcea33608b6
Authored: 2023-09-12 21:29:20 +0200
Committed: 2023-09-14 09:45:41 +0200

[Editor] Change the style of the bounding box and the resizers (bug 1852897)

Files Modified:

• src/display/editor/editor.js
• src/display/editor/freetext.js
• src/display/editor/ink.js
• web/annotation_editor_layer_builder.css

---

720963bbe6d48e2c28ec326377d0459a8cab96a2 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/720963bbe6d48e2c28ec326377d0459a8cab96a2
Authored: 2023-09-13 10:51:13 +0200
Committed: 2023-09-13 10:51:25 +0200

[Editor] Move an editor in the DOM just after having moved it on the screen

It avoids to have to remember to call moveInDOM after fixAndSetPosition is called.

Files Modified:

• src/display/editor/annotation_editor_layer.js
• src/display/editor/editor.js

---

50937a3539720e92b0090ac0d6c191fd48eb1612 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/50937a3539720e92b0090ac0d6c191fd48eb1612
Authored: 2023-09-12 13:09:58 +0200
Committed: 2023-09-12 13:26:57 +0200

Ensure that the entire PDF document is loaded before we begin saving it

When I started looking at PR 16938 it occurred to me that some of the new structTree-methods are synchronously accessing certain dictionary-data (not used during "normal" structTree-parsing), which may not be generally safe since everything in a dictionary could be a reference (and the relevant data may not have been loaded yet).

Rather than suggesting that we make all those new methods even more asynchronous, to me the overall simplest and safest solution is to ensure that the entire PDF document has been loaded before we begin saving it. In practice this shouldn't really affect "performance" of saving noticeably, since it's always depended on the entire PDF document being downloaded.

Finally note that with the exception of the PDF document possibly not having been fully downloaded when saving is triggered, all other "global" document properties are pretty much guaranteed to already be available at this point.

Files Modified:

• src/core/worker.js

---

56466048832b935e80c878c262e644861cfefe47 by Calixte Denizet

https://github.com/mozilla/pdf.js/commit/56466048832b935e80c878c262e644861cfefe47
Authored: 2023-09-12 12:17:24 +0200
Committed: 2023-09-12 12:17:24 +0200

[Editor] Only get back the focus when it has been lost after an editor has been moved in the DOM

Files Modified:

• src/display/editor/annotation_editor_layer.js

---

66507ccae8aa55792d306ca350443d6b95d67b42 by Tim van der Meij

https://github.com/mozilla/pdf.js/commit/66507ccae8aa55792d306ca350443d6b95d67b42
Authored: 2023-09-10 15:44:07 +0200
Committed: 2023-09-10 15:47:04 +0200

Enable unit test "creates pdf doc from non-existent URL"

The unit test is re-enabled because it no longer seems to fail after 10
runs on Linux where this used to fail often. Code inspection also shows
that the code is correct and should raise the previous exception
(anymore). Finally, a lot has changed since this test was disabled such
as new Jasmine versions, new Linux bot OS version and new browser
versions.

Files Modified:

• test/unit/api_spec.js

---

981ef9e31ed823cae29d534e64e8dc449dc9c827 by Tim van der Meij

https://github.com/mozilla/pdf.js/commit/981ef9e31ed823cae29d534e64e8dc449dc9c827
Authored: 2023-09-09 15:37:23 +0200
Committed: 2023-09-09 17:53:43 +0200

Update translations

Files Modified:

• l10n/en-CA/viewer.properties
• l10n/es-ES/viewer.properties
• l10n/oc/viewer.properties
• l10n/th/viewer.properties

---

f42d70a24e2138f00bd696808aa30990125152ef by Tim van der Meij

https://github.com/mozilla/pdf.js/commit/f42d70a24e2138f00bd696808aa30990125152ef
Authored: 2023-09-09 15:28:17 +0200
Committed: 2023-09-09 17:53:43 +0200

Update packages

Files Modified:

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

---

b5b061cdb6a2798d433207189d4d3b9d69508045 by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/b5b061cdb6a2798d433207189d4d3b9d69508045
Authored: 2023-09-07 15:31:32 +0200
Committed: 2023-09-08 13:27:31 +0200

Slightly re-factor the parameter handling in Catalog.parseDestDictionary

While it makes sense to check that the destDict parameter is indeed a Dictionary, since that data comes from the PDF document itself, the resultObj parameter is an internal PDF.js implementation detail that should always be correct (or tests will fail).

Files Modified:

• src/core/catalog.js

---

df9cce39c09cde3a4fa5f523c1115e83280a163f by Jonas Jenwald

https://github.com/mozilla/pdf.js/commit/df9cce39c09cde3a4fa5f523c1115e83280a163f
Authored: 2023-09-07 14:14:35 +0200
Committed: 2023-09-08 13:27:27 +0200

Slightly reduce asynchronicity when parsing Annotations

Over time the amount of "document level" data potentially needed during parsing of Annotations have increased a fair bit, which means that we currently need to ensure that a bunch of data is available for each individual Annotation.
Given that this data is "constant" for a PDF document we can instead create (and cache) it lazily, only when needed, before starting to parse the Annotations on a page. This way the parsing of individual Annotations should become slightly less asynchronous, which really cannot hurt.

An additional benefit of these changes is that we can reduce the number of parameters that need to be explicitly passed around in the annotation-code, which helps overall readability in my opinion.

One potential drawback of these changes is that the AnnotationFactory.create method no longer handles "everything" on its own, however given how few call-sites there are I don't think that's too much of a problem.

Files Modified:

• src/core/annotation.js
• src/core/catalog.js
• src/core/document.js
• src/core/pdf_manager.js
• test/unit/annotation_spec.js

---

Comment 1

[Update Bot]

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

Comment 2

[Update Bot]

Attachment: Bug 1853478 - Update PDF.js to 586d3add465fa9179c85a8fd5f10b874707a22eb

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1250c7a9c154
Update PDF.js to 586d3add465fa9179c85a8fd5f10b874707a22eb r=pdfjs-reviewers,calixte

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/1250c7a9c154