Closed Bug 1849299 Opened 7 months ago Closed 6 months ago

Update PDF.js to new version c72cb5436def2d6f2e703447c8b901e92b4dd403 from 2023-08-15 14:44:18


(Firefox :: PDF Viewer, enhancement)




118 Branch
Tracking Status
firefox118 --- fixed


(Reporter: update-bot, Assigned: calixte)


(Blocks 1 open bug)


(Whiteboard: [3pl-filed][task_id: ajT1J9HJQ0a5DzlMxLzltw])


(1 file)

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

toolkit/components/pdfjs/content/build/pdf.js | 36 ++++++++-------
toolkit/components/pdfjs/content/build/pdf.scripting.js | 4 +-
toolkit/components/pdfjs/content/build/pdf.worker.js | 6 +-
toolkit/components/pdfjs/content/web/viewer-geckoview.js | 6 +-
toolkit/components/pdfjs/content/web/viewer.js | 6 +-
toolkit/components/pdfjs/moz.yaml | 4 +-
6 files changed, 33 insertions(+), 29 deletions(-)

29b2050ac20442e69390a758bd294486537bce43 by Jonas Jenwald
Authored: 2023-08-15 15:12:17 +0200
Committed: 2023-08-15 15:12:17 +0200

Improve the "write a new annotation, save the pdf and check that the text content is correct" unit-test (PR 16559 follow-up)

Currently this unit-test will pass just fine if compression is disabled, e.g. by commenting out the relevant code in the src/core/writer.js file.
While we don't have a simple way of directly checking that the Annotation text-content is compressed, we can however use the resulting file-size as a fairly good proxy. (Note that if compression is disabled the file-size is more than doubled.)

Files Modified:

  • test/unit/api_spec.js

6669a992992c5636c866c6b31acafcae0a47465c by Jonas Jenwald
Authored: 2023-08-13 08:55:58 +0200
Committed: 2023-08-13 08:55:58 +0200

Remove the "no-babel-preset" comment used with the LIB build-target (PR 16829 follow-up)

Similar to the changes in PR 16829, this no longer seems necessary now.

Files Modified:

  • gulpfile.mjs
  • src/core/glyphlist.js

66437917dbe6501ee67df5a4201ae94b0b635fa2 by Jonas Jenwald
Authored: 2023-08-12 18:27:01 +0200
Committed: 2023-08-12 21:21:50 +0200

Avoid using the global workerPort when destruction has started, but not yet finished (issue 16777)

Given that the PDFDocumentLoadingTask.destroy()-method is documented as being asynchronous, you thus need to await its completion before attempting to load a new PDF document when using the global workerPort.
If you don't await destruction as intended then a new getDocument-call can remain pending indefinitely, without any kind of indication of the problem, as shown in the issue.

In order to improve the current situation, without unnecessarily complicating the API-implementation, we'll now throw during the getDocument-call if the global workerPort is in the process of being destroyed.
This part of the code-base has apparently never been covered by any tests, hence the patch adds unit-tests for both the correct usage (awaiting destruction) as well as the specific case outlined in the issue.

Files Modified:

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

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.

Assignee: nobody → cdenizet
Pushed by
Update PDF.js to c72cb5436def2d6f2e703447c8b901e92b4dd403 r=pdfjs-reviewers,calixte
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch
You need to log in before you can comment on or make changes to this bug.