Provide a js fallback when the wasm version of openjpeg is failing to load (bug 1935076)

[calixteman]

No description provided.

[calixteman]

@Snuffleupagus I've two problems with this PR:

• gulp lint --fix is taking for ever: it's because of external/openjpeg/openjpeg_nowasm_fallback.js but normally no linter should run on it.
• the await import shouldn't be converted into webpack stuff when building for m-c

Could you help me to fix these issues ?

[calixteman]

@Snuffleupagus if you see a better way to use the fallback, don't worry to take the ownership of this PR.

[Snuffleupagus]

• gulp lint --fix is taking for ever: it's because of external/openjpeg/openjpeg_nowasm_fallback.js but normally no linter should run on it.

That folder should already being excluded from linting, given

pdf.js/eslint.config.mjs

Line 37 in 34ef74c

"external/openjpeg/",

Is the problem perhaps rather the web/wasm/ folder, because if so I believe that the following diff should fix that?

diff --git a/eslint.config.mjs b/eslint.config.mjs
index 887e013bb..27893feea 100644
--- a/eslint.config.mjs
+++ b/eslint.config.mjs
@@ -39,6 +39,7 @@ export default [
       "test/tmp/",
       "test/pdfs/",
       "web/locale/",
+      "web/wasm/",
       "**/*~/",
     ],
   },

• the await import shouldn't be converted into webpack stuff when building for m-c

Yes, that problem is kind of "expected" unless you explicitly tell Webpack to leave the import alone.
Please refer to the following examples to see how we handle that:

• pdf.js/web/app.js

  Lines 284 to 287 in 34ef74c

  	const { PDFBug } =
  	typeof PDFJSDev === "undefined"
  	? await import(AppOptions.get("debuggerSrc")) // eslint-disable-line no-unsanitized/method
  	: await __non_webpack_import__(AppOptions.get("debuggerSrc"));

• pdf.js/web/generic_scripting.js

  Lines 39 to 42 in 34ef74c

  	const sandbox =
  	typeof PDFJSDev === "undefined"
  	? import(sandboxBundleSrc) // eslint-disable-line no-unsanitized/method
  	: __non_webpack_import__(sandboxBundleSrc);

[Snuffleupagus]

Also, how do we (easily) test this?
Could we e.g. have a test in mozilla-central, since I'm assuming that it should be easy (famous last words) to temporarily disable WebAssembly via a preference during testing?

[calixteman]

I just added a ref test to check the nowasm path.
Yep it'd make sense to have one too on the m-c side, I'll try to create a pdf with a monochrome jp2 image and check the pixels.

[Snuffleupagus]

Do we also want to re-init the new #importModuleResolver field in the cleanup method?

pdf.js/src/core/jpx.js

Lines 108 to 110 in e3ea926

	static cleanup() {
	this.#modulePromise = null;
	}

[Snuffleupagus]

Should we also change

pdf.js/src/core/jpx.js

Line 39 in b2a860c

if (!this.#buffer) {

to the following (since this.#buffer may never be set when we fallback to JS-decoding)?

if (!this.#modulePromise) {

[Snuffleupagus]

/botio unittest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_unittest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/36e13c35f49e178/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_unittest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/a60c9d7055aa88d/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.241.84.105:8877/36e13c35f49e178/output.txt

Total script time: 2.54 mins

• Unit Tests: Passed

[moz-tools-bot]

From: Bot.io (Windows)

---

Success

Full output at http://54.193.163.58:8877/a60c9d7055aa88d/output.txt

Total script time: 7.80 mins

• Unit Tests: Passed

[Snuffleupagus]

/botio browsertest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_browsertest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/70f9e28a5045ef7/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_browsertest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/61020c03a6af55c/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.241.84.105:8877/70f9e28a5045ef7/output.txt

Total script time: 17.18 mins

• Regression tests: Passed

[Snuffleupagus]

r=me, thank you.

Reminder: When updating mozilla-central, the new JS file needs to be added to https://searchfox.org/mozilla-central/source/toolkit/components/pdfjs/jar.mn

[moz-tools-bot]

From: Bot.io (Windows)

---

Success

Full output at http://54.193.163.58:8877/61020c03a6af55c/output.txt

Total script time: 30.53 mins

• Regression tests: Passed

[Snuffleupagus]

It just occurred to me that the way the wasmUrl option is currently implemented won't work correctly in general, now that we also need to be able to import a fallback JS file on the worker-thread.
This should however not affect mozilla-central and I've already got a WIP patch to improve things, so I'd suggest that we land this PR as-is and improve things in a follow-up.

[Snuffleupagus]

/botio makeref

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_makeref from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/9efd0b43cf36159/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_makeref from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/56b8e129c88d047/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.241.84.105:8877/9efd0b43cf36159/output.txt

Total script time: 16.81 mins

• Make references: Passed
• Check references: Passed

[moz-tools-bot]

From: Bot.io (Windows)

---

Success

Full output at http://54.193.163.58:8877/56b8e129c88d047/output.txt

Total script time: 30.35 mins

• Make references: Passed
• Check references: Passed