1912839 - Update PDF.js to new version d0fbfe10c5b43a8011e669bd6aa6bd6fc4b8ce9b from 2024-08-12 17:06:21

Status: RESOLVED DUPLICATE of bug 1913880

(Firefox :: PDF Viewer, enhancement)

Description

[Update Bot]

This update covers 4 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 | 40 +-
toolkit/components/pdfjs/content/build/pdf.scripting.mjs | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.mjs | 37 +-
toolkit/components/pdfjs/content/web/viewer-geckoview.mjs | 17 +-
toolkit/components/pdfjs/content/web/viewer.css | 297 +++++++------
toolkit/components/pdfjs/content/web/viewer.html | 40 +-
toolkit/components/pdfjs/content/web/viewer.mjs | 20 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
9 files changed, 200 insertions(+), 261 deletions(-)

---

aebb8534f376930b6fc9552724527065e3492854 by Jonas Jenwald <[e-mail]>

https://github.com/mozilla/pdf.js/commit/aebb8534f376930b6fc9552724527065e3492854
Authored: 2024-08-12 11:59:13 +0200
Committed: 2024-08-12 12:26:35 +0200

Limit base-class initialization checks to development and TESTING modes

We have a number of base-classes that are only intended to be extended, but never to be used directly. To help enforce this during development these base-class constructors will check for direct usage, however that code is obviously not needed in the actual builds.

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

Files Modified:

• src/core/base_stream.js
• src/core/colorspace.js
• src/core/crypto.js
• src/core/font_renderer.js
• src/core/image_utils.js
• src/core/name_number_tree.js
• src/core/pattern.js
• src/core/pdf_manager.js
• src/display/base_factory.js
• src/display/editor/editor.js
• src/display/pattern_helper.js
• src/shared/util.js
• web/app_options.js
• web/base_tree_viewer.js
• web/external_services.js
• web/preferences.js

---

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

https://github.com/mozilla/pdf.js/commit/5193adf1fd9d9e8281a8c9aecc9f743562982ef9
Authored: 2024-08-11 18:16:51 +0200
Committed: 2024-08-11 18:27:04 +0200

Group and scope the secondary toolbar rules using CSS nesting

The secondary toolbar CSS rules predate the general availability of CSS
nesting, which makes them more difficult to understand and change
safely. The primary issues are that the rules are spread over the
viewer.css file, they share blocks with other elements and the scope
of the rules is sometimes bigger than necessary.

This refactoring groups all remaining secondary toolbar rules together,
scoped to the top-level #secondaryToolbar element, for improved
overview and isolation. Note that this patch only intends to move the
existing rules around and not change any behavior.

Co-authored-by: Calixte Denizet <[e-mail]>

Files Modified:

• web/viewer.css

---

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

https://github.com/mozilla/pdf.js/commit/2a22424c954866da395bc2807d65da9c483ef003
Authored: 2024-08-11 15:04:38 +0200
Committed: 2024-08-11 17:48:25 +0200

Remove the secondaryToolbarButton CSS class

Secondary toolbar buttons are toolbar buttons with some extra rules,
mainly to make them wider and have visible labels. However, this
similarity is currently not clearly reflected in the implementation
because the secondary toolbar buttons use a different CSS class,
secondaryToolbarButton, compared to the other toolbar buttons that
use the toolbarButton CSS class. This also causes some duplication
in the rules and requires extra care to keep the common bits for the
secondaryToolbarButton class in sync with the toolbarButton class.

Fortunately, now that we have a dedicated CSS scope for the secondary
toolbar, we can simplify this by giving all secondary toolbar buttons
the toolbarButton class and explicitly listing the required overrides
in the #secondaryToolbar scope instead. Doing so removes most of the
special-casing for secondary toolbar buttons while explicitly listing
the differences in a single place for a better overview. It also lays
the foundation for making all toolbar buttons respect the
browser.uidensity Firefox preference later by reducing differences.

Co-authored-by: Calixte Denizet <[e-mail]>

Files Modified:

• web/viewer.css
• web/viewer.html

---

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

https://github.com/mozilla/pdf.js/commit/97b761dfbf1309693fab722262196514f09923ed
Authored: 2024-08-11 13:40:57 +0200
Committed: 2024-08-11 13:52:23 +0200

Group and scope the secondary toolbar button container/icon rules using CSS nesting

The secondary toolbar CSS rules predate the general availability of CSS
nesting, which makes them more difficult to understand and change
safely. The primary issues are that the rules are spread over the
viewer.css file, they share blocks with other elements and the scope
of the rules is sometimes bigger than necessary.

This refactoring groups all CSS rules for the secondary toolbar button
container/icons together, scoped to the top-level #secondaryToolbar
element, for improved overview and isolation. Note that this patch only
intends to move the existing rules around and not change any behavior.
Moreover, this patch does not move the rules for the secondary toolbar
itself and the secondary toolbar buttons; those will be part of a
follow-up patch and will be easier once this is in place first.

Co-authored-by: Calixte Denizet <[e-mail]>

Files Modified:

• web/viewer.css

---

Comment 2

[Update Bot]

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

Comment 3

[Update Bot]

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

Needs Investigation (Possible Intermittents):

• source-test-taskgraph-diff - 4 of 4 failed on the same (retriggered) task (failed: VoiajFKATj60ro28Z3wPrw, SBDVyxK4TMCbuS1GGe24_Q, S2L6wNMuSBqJsYYJ8xPl3w, GCOiZlg-SgW67JUhn9cwnQ)

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 4

[Update Bot]

This bug is being closed because a newer revision of the library is available.
This bug will be marked as a duplicate of it (because although this bug is older, it is superseded by the newer one).