Viewer may fail rendering silently if the server doesn't correctly identify .mjs files as JavaScript modules

[digeomel]

Hi, this is just a heads-up for other devs who may face the same situation. I didn't read anything about this in the documentation. Although it is mentioned that the component relies on viewer.min.js and pdf.worker.min.js to be in the assets folder, what is not mentioned, probably because it should be obvious in modern server setups, is that these files are now JS modules, so viewer.mjs and pdf.worker.mjs and they have to be served with the correct mimetype, that is text/javascript. In our case, we have an old Java/Spring back-end which doesn't seem to have the correct modern settings for serving lots of different files including .mjs and so we were getting this error:

Failed to load module script: Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.

The problem is, I didn't get this error locally because of course ng serve uses the correct mimetype. and 2nd, Chrome was not throwing any error in the console, I only saw this on Edge. The viewer would just fail silently, not load anything else after the initial call to get viewer.min.js.

And this happened after we upgraded from v18.1.14 to v20.5.2.

[stephanrauh]

I feel you! I've double-checked the documentation, and you're right - the getting-started page wasn't up-to-date. I've updated every reference to the .js files. Also, I've deleted the references to the pdf.mjs file. It doesn't exist anymore, I've merged it with the viewer-*.mjs file.

Just for the records, here are some useful links to the documentation:

• https://pdfviewer.net/extended-pdf-viewer/troubleshooting describes how how to configure the MIME type:
• https://pdfviewer.net/extended-pdf-viewer/getting-started mentions the MIME type and links to the troubleshooting page (soon).

[stephanrauh]

@digeomel I've converted your issue to a discussion. This way, I hope users are able so see your post easier. Issues tend to get closed, and after that, they are sort of invisible.

[digeomel]

Thank you for the extremely swift reply and documentation update! Keep up the good work!

[digeomel]

I just discovered that the PDF worker is in turn trying to load a WASM file from a location that doesn't exist?

[digeomel]

In fact it looks like there are multiple WASM files that the PDF worker is trying to load outside the /assets folder:

[stephanrauh]

Yes, you're right. There was already an issue for that: #2973. Please update to version 24.2.3 - it solves the bug.