Viewer is throwing exception in Google Chrome

Hi team,

Got a strange one here. When trying to load in any document, I am getting the below exception in the console. The viewer itself loads fine, but the document load fails. This only seems to happen in Google Chrome.

The strangest thing is that it happened on my PC last week, and I tried everything I could think of to fix it, as I thought it was something on my end since the issue wasn’t happening on my colleagues PCs - re-install viewer, chrome update, windows update, update node, wipe and re-pull repo etc.

Anyway, the exception has miraculously disappeared from my computer today. However, now its happening to one of my colleagues.

(index)
Value
UI version	"7.2.0"
Core version	"7.2.2"
Build	"MS8xMi8yMDIxfDcxODAxYzM3NA=="
WebViewer Server	false
Full API	false
Object
ExternalPdfPartRetriever.chunk.js:6 Uncaught (in promise) TypeError: Object(...) is not a function
    at ExternalPdfPartRetriever.chunk.js:6
    at new Promise (<anonymous>)
    at h.getFile (ExternalPdfPartRetriever.chunk.js:6)
    at __webpack_exports__.loadAsync (PDFJSDocumentType.js:2271)
    at CoreControls.js:211
    at new Promise (<anonymous>)
    at ca.Ep (CoreControls.js:211)
    at CoreControls.js:747
    at n (CoreControls.js:198)
    at Object.next (CoreControls.js:196)
ExternalPdfPartRetriever.chunk.js:3 Uncaught TypeError: Object(...) is not a function
    at XMLHttpRequest.<anonymous> (ExternalPdfPartRetriever.chunk.js:3)

Thanks, Luke

Hey!

This is a weird one :wink:

Are you able to send some code showing how you are loading your document?

Also, does it happen on all documents or just a specific one?

Thanks
Logan

Hi Logan,

Here is some React code illustrating how we load in documents. Basically we just pass in a URL to the pdf using the pdfUrl prop. It works fine in Edge and Firefox, so the issue seems to be Chrome specific. It happens on all PDFs we’ve tried.


image
image
image

Cheers, Luke

HI Logan,

I have some more information that might help to diagnose the problem. So far, we have only noticed this happening in development evironments (localhost). During these sessions, when the viewer starts up, it spits out the following in the browser console:

PDFJSDocumentType.js:2208 PDFJS.express: Development environment detected. This license key is currently registered to <mydomain>

We decided to see what happens if we tunneled the app away from localhost through ngrok. Lo and behold, the PDF documents are now loading without issue! So on the same machine and same browser, localhost fails yet the tunneled connection works. Also, there is no log on the tunneled connection like the one mentioned above.

This leads us to believe that the problem exists only when the viewer detects a devolpment environment.

Hope this helps, Luke.

Hey there!

Thanks for all the information, that is very helpful.

As a temporary workaround, removing the license key in your local environment might work.

I cannot reproduce the issue in a local environment, even with a real license key.

Can you confirm that all of Express’ assets are being correctly loaded in your dev environment? The document will not load if pdfjsexpress.wasm is not able to load properly, or if there is any tampering or misconfiguration in the environment.

Thanks,
Logan

Hi Logan,

Removing the license key didn’t help unfortunately.

I can confirm that the assests are loading in, including the pdfjsexpress.wasm (see image below).

I can’t unfortunately provide exact reproduction steps as it is only currently happening on one of our machines.

Here are some more screen shots of the error inside ExternalPdfPartRetriever
image

My understanding of this is that ca.a and ca.b need to be functions for this code to work, so maybe there are bad parameters being passed into the ExternalPdfPartReriever. What might cause that to happen though?

Luke

Hi Logan,

After doing a hard reload in the browser, the problem now seems to be gone. Strange because I’m pretty sure we have tried this already. Anyway, we’ll update you if the issues comes back.

Thanks, Luke.