Right now WebKitGTK uses Mozilla's PDF.js and keeps it in the source tree at Source/ThirdParty/pdfjs/. The README.webkit file there says:

Has that obstacle been surmounted? Debian has a libjs-pdf package already, and by using that any doubt about the wholesomeness of these bundled sources can be alleviated. The contents of /usr/share/javascript/pdf/ look like they correspond to this WebKit subdirectory. The README.webkit file does specify steps to update the bundled PDF.js but there don't seem to be patches or meaningful changes; it's more for the sake of tidyness, it seems. The packaged version of PDF.js ought to work without tweaks.

To be honest, I can't find which WebKit binary package(s) get this copy of PDF.js bundled into them or where they are. The remaining choice is whether WebKit should use the installed libjs-pdf at runtime, or whether to use libjs-pdf at build-time and have those artifacts folded into the binary package.
The latter would probably be very easy, maybe replacing the files in Source/ThirdParty/pdfjs/ with symlinks to the system-wide files so the build process will use those. Our WebKit package may need to set Built-Using or Static-Built-Using depending on particular details of licenses and such.

In principle it would be nice if WebKit could simply use what's in /usr/share/javascript/ directly, similar to how system-wide WebExtensions work. This would probably need upstream coordination and since I can't even find where PDF.js is lurking in the binaries now, this is kind of out of the question.

Has this been brought up before? I couldn't find a bug, but it looks like we're very fortunate to have PDF.js already in Debian and a clear set of instructions for substituting our version for theirs.

Those files are bundled inside the WebKitGTK library as a GResource:

$ gresource list /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4 | grep pdfjs

And if I'm not wrong they are loaded at runtime from this file:

   Source/WebCore/loader/soup/ResourceLoaderSoup.cpp

I suppose it's possible to have a build flag to use an external PDF.js
library, but that's a change that should be discussed with upstream in
https://bugs.webkit.org/

Berto

Talking to one the upstream WebKitGTK developers I saw that the
version of PDF.js shipped by Debian (2.14.305, from 2022) is quite
outdated compared to the one shipped by WebKit (4.1.392, 2024), so
this would be a downgrade.

In this situation I don't think that this is a good idea.

Berto