Skip to content

Attempt to expose e.g. pdfjsLib globally regardless of how the library is imported (issue 16778) #16790

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 6, 2023

Conversation

Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Aug 3, 2023

We obviously don't want to re-introduce any require usage in e.g. the viewer, since we should strive to only use native import statements wherever possible.[1]
Hopefully exposing e.g. the library globally in more cases won't break anything, however it's somewhat difficult for me to imagine all the ways in which third-party users may be accessing the PDF.js library. (Given the lack of a runnable test-case in the issue, I also cannot guarantee that this is enough to fully address the problem.)


[1] Ideally we should probably not rely on e.g. pdfjsLib being globally available in the built viewer, and rather always import the library instead.
Unfortunately this would require larger (possibly breaking) changes in the builds that we provide, however note that Firefox only recently got support for import in workers and that Webpack still only have experimental support for outputting "proper" modules.

@Snuffleupagus Snuffleupagus linked an issue Aug 3, 2023 that may be closed by this pull request
@Snuffleupagus
Copy link
Collaborator Author

For the built pdf.js file this patch gives the following changes when comparing against the master branch:

--- C:\Users\Jonas\Desktop\pdf.js
+++ C:\Users\Jonas\Git\pdf.js\build\generic\build\pdf.js
@@ -22,11 +22,11 @@
 
 (function webpackUniversalModuleDefinition(root, factory) {
 	if(typeof exports === 'object' && typeof module === 'object')
-		module.exports = factory();
+		module.exports = root.pdfjsLib = factory();
 	else if(typeof define === 'function' && define.amd)
-		define("pdfjs-dist/build/pdf", [], factory);
+		define("pdfjs-dist/build/pdf", [], () => { return (root.pdfjsLib = factory()); });
 	else if(typeof exports === 'object')
-		exports["pdfjs-dist/build/pdf"] = factory();
+		exports["pdfjs-dist/build/pdf"] = root.pdfjsLib = factory();
 	else
 		root["pdfjs-dist/build/pdf"] = root.pdfjsLib = factory();
 })(globalThis, () => {
@@ -966,7 +966,7 @@
   }
   const fetchDocParams = {
     docId,
-    apiVersion: '3.10.23',
+    apiVersion: '3.10.24',
     data,
     password,
     disableAutoFetch,
@@ -2723,9 +2723,9 @@
     }
   }
 }
-const version = '3.10.23';
+const version = '3.10.24';
 exports.version = version;
-const build = '2747928a5';
+const build = '70a1cc5b0';
 exports.build = build;
 
 /***/ }),
@@ -17470,8 +17470,8 @@
 var _annotation_layer = __w_pdfjs_require__(29);
 var _worker_options = __w_pdfjs_require__(14);
 var _xfa_layer = __w_pdfjs_require__(32);
-const pdfjsVersion = '3.10.23';
-const pdfjsBuild = '2747928a5';
+const pdfjsVersion = '3.10.24';
+const pdfjsBuild = '70a1cc5b0';
 })();
 
 /******/ 	return __webpack_exports__;

@Snuffleupagus
Copy link
Collaborator Author

/botio test

@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Linux m4)


Received

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

Live output at: http://54.241.84.105:8877/29a9816998e5997/output.txt

@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Windows)


Received

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

Live output at: http://54.193.163.58:8877/72079013018d43f/output.txt

…ary is imported (issue 16778)

We obviously don't want to re-introduce any `require` usage in e.g. the viewer, since we should strive to only use native `import` statements wherever possible.[1]
Hopefully exposing e.g. the library globally in more cases won't break anything, however it's somewhat difficult for me to imagine all the ways in which third-party users may be accessing the PDF.js library. (Given the lack of a runnable test-case in the issue, I also cannot guarantee that this is enough to fully address the problem.)

---
[1] Ideally we should probably not rely on e.g. `pdfjsLib` being globally available in the *built* viewer, and rather always `import` the library instead.
Unfortunately this would require larger (possibly breaking) changes in the builds that we provide, however note that Firefox only recently got support for `import` in workers and that Webpack still only have *experimental* support for outputting "proper" modules.
@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Linux m4)


Failed

Full output at http://54.241.84.105:8877/29a9816998e5997/output.txt

Total script time: 27.21 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Integration Tests: FAILED
  • Regression tests: FAILED
  different ref/snapshot: 16
  different first/second rendering: 2

Image differences available at: http://54.241.84.105:8877/29a9816998e5997/reftest-analyzer.html#web=eq.log

@moz-tools-bot
Copy link
Collaborator

From: Bot.io (Windows)


Failed

Full output at http://54.193.163.58:8877/72079013018d43f/output.txt

Total script time: 39.14 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Integration Tests: FAILED
  • Regression tests: FAILED
  errors: 1
  different ref/snapshot: 28

Image differences available at: http://54.193.163.58:8877/72079013018d43f/reftest-analyzer.html#web=eq.log

@timvandermeij timvandermeij merged commit b67c609 into mozilla:master Aug 6, 2023
@timvandermeij
Copy link
Contributor

Looks good to me; thank you!

@Snuffleupagus Snuffleupagus deleted the addGlobalExports branch August 6, 2023 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pdf_viewer broken in 3.9.179 when using Webpack
3 participants