Bug 240457

Summary:	PDF.js is not shipped in preferred modifiable form
Product:	WebKit	Reporter:	Michael Catanzaro <mcatanzaro>
Component:	PDF	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED WONTFIX
Severity:	Normal	CC:	bugs-noreply, mcatanzaro, ntim, thorton
Priority:	P2
Version:	WebKit Nightly Build
Hardware:	PC
OS:	Linux
Bug Depends on:
Bug Blocks:	235969

Description Michael Catanzaro 2022-05-16 08:55:45 PDT

I was going to prepare an update to PDF.js 2.14.305 today, but noticed we are shipping "prebuilt" PDF.js under Source/ThirdParty/pdfjs. Major Linux distros do not allow prebuilt sources. It does not matter that it's not minified/obfuscated: what matters is that it's not the "preferred modifiable form" of the software. We should only ship the preferred modifiable form, and "build" that as part of the CMake/XCode build process if needed/desired.

According to https://github.com/mozilla/pdf.js/wiki/Setup-PDF.js-in-a-website#build-pdfjs-from-source, the build process is just one command: 'gulp generic', using gulp from https://gulpjs.com/. I've never heard of it, and it's not packaged in Fedora at all, so if we were to do this, I imagine most or all distros would just disable PDF.js entirely rather than bother with it.

We still have PDF.js in Epiphany because there have not been any WebKitGTK releases with PDF.js included yet. Epiphany ships the sources as-is, with no attempt made to build it. That works fine. I didn't even realize that it was possible to "build" it until today. I bet this would be fine for WebKit too, since it looks like the build process seems to be primarily designed to reduce the number of HTTP requests involved, which isn't relevant to WebKit as these are local resources? I'm not at all familiar with the advantages/disadvantages of shipping the original sources vs. the prebuilt sources, other than that prebuilt is not an option for Linux. I wonder what the disadvantages of not building them would really be.

My proposal is to just switch to the non-prebuilt sources, and move on. I can prepare a patch for this if it would be welcome. Tim, does that sound OK? Alternatively, we could ship prebuilt for macOS and non-prebuilt for Linux, but that seems annoying.

(I would also add a README.webkit with instructions for updating PDF.js.)

Comment 1 Tim Nguyen (:ntim) 2022-05-16 09:17:14 PDT

I don't mind either way tbh. As long as the update process is straightforward and doesn't involve manually editing/patching the PDF.js source code, I'm good with it. Feel free to do it on all platforms, happy to review.

If you could document the instructions for updating, that would be great!

Also, it's worth noting that bundle size is a problem that we'd like to tackle at some point, so if you have solutions for that, I'd be curious to know what it is.

Comment 2 Tim Nguyen (:ntim) 2022-05-16 09:17:27 PDT Comment hidden (duplicate, obsolete)

Happy to review either way!

Comment 3 Michael Catanzaro 2022-05-16 10:25:20 PDT

(In reply to Tim Nguyen (:ntim) from comment #1)
> I don't mind either way tbh. As long as the update process is
> straightforward and doesn't involve manually editing/patching the PDF.js
> source code, I'm good with it. Feel free to do it on all platforms, happy to
> review.
> 
> If you could document the instructions for updating, that would be great!

Well you've already ensured that this can be done without patching, with your split between the third-party code and the pdfjs-extras in WebCore. (That's nicer than the Epiphany version, which requires some patching.)

Accordingly, the instructions for updating should be easy.

> Also, it's worth noting that bundle size is a problem that we'd like to
> tackle at some point, so if you have solutions for that, I'd be curious to
> know what it is.

Hm, for GTK/WPE everything gets compressed automatically with gzip. If we want to do better than that, I suppose we'd be looking at using gulp and also perhaps minification? This is far from my expertise.

Comment 4 Tim Nguyen (:ntim) 2022-05-16 14:16:26 PDT

I'd be curious to see a proof of concept of what you think this could look like, to ship directly from the source.

Comment 5 Michael Catanzaro 2022-05-16 14:52:11 PDT

Major correction: Epiphany is actually shipping the prebuilt sources too. :P

We previously had a request from Debian to remove the .map files, which are already not present in WebKit's dist, so... that kinda implies they're OK with shipping sources preprocessed by gulp already. Accordingly, I'm just going to go ahead and close this and hope nobody complains. It doesn't seem practical to do more for now. If we receive complaints, then we can reconsider.

I'll still look into updating to the latest version and adding a README.

Comment 6 Michael Catanzaro 2022-05-17 04:50:13 PDT

(In reply to Tim Nguyen (:ntim) from comment #1)
> Also, it's worth noting that bundle size is a problem that we'd like to
> tackle at some point, so if you have solutions for that, I'd be curious to
> know what it is.

It looks like it's about 4 MB for us, see https://bugs.webkit.org/show_bug.cgi?id=238023#c2. That's with all the .html, .js, .css, .svg, and .properties files gzip compressed.