Simple PDF with standard Courier font won't load in pdf.js version 2.3.200 running in Chrome version 92

Attach (recommended) or Link to PDF file here:

Configuration:

• Web browser and its version: Chrome 92
• Operating system and its version: Windows 10
• PDF.js version: 2.3.200
• Is a browser extension: No

Steps to reproduce the problem:

1. Load the attached 1-page PDF in pdf.js 2.3.200 using Chrome 92

What is the expected behavior?

The PDF should load properly. It loaded fine in all previous versions of Chrome, but will not load in Chrome version 92.

What went wrong?

The PDF fails to load properly. The text layer appears to be created, but the canvas is not generated properly. The PDF appears to be blank on the screen.

The following warning appears in the Chrome console:

Warning: getOperatorList - ignoring errors during "GetOperatorList: page 0" task: "DataCloneError: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': function at() { [native code] } could not be cloned.".

This appears to have something to do with the source PDF using the standard Courier font (not an embedded font). I have generated newer PDFs using an embedded font and they load properly in pdf.js 2.3.200 in Chrome 92. I debugged the pdf.js code and it does appear to be throwing an exception in the font loading code. I tried loading the same test PDF into some newer versions of pdf.js and it does appear to load in 2.5.207 and newer when running in Chrome 92. There is something about the combination of the 2.3.200 version of pdf.js, Chrome 92, and the font situation that is resulting in the issue.

Upgrading to a newer version of pdf.js is not a short-term solution for us because we still have a few users running IE11. I am hoping someone can help shed some light on the issue and perhaps point to the change that was made in Chrome 92 that is causing this issue. If it is a Chrome bug, I can report it to Google or maybe there is a Chrome flag that can be adjusted to correct the issue?

Thanks!

test.pdf

[mullery]

We isolated the issue and confirmed it is a defect in pdf.js that was fixed in v2.5. All earlier versions of pdf.js will encounter the problem when opening a PDF containing the standard Courier font (not an embedded font) on Chrome 92.

The problem is in fonts.js. Prior to version 2.5, The exportData() function would copy all font properties to a data object prior to a postMessage call to send the data to another thread. In Chrome 92, the widths property of the font object contains a mysterious at() function. Functions cannot be cloned and passed via postMessage. There is a TODO comment in the older exportData() function that reads:

// TODO remove enumerating of the properties, e.g. hardcode exact names.

The exportData() function was refactored in 2.5, with the refactored code preventing the issue in Chrome 92.

Here’s the commit that fixes the issue:

https://github.com/mozilla/pdf.js/pull/11773/commits/664f7de54097c799b25979cd2af5141fd36f7e66

We were forced to create a custom build of pdf.js v2.3.200 where we applied the same fix in order to resolve the issue and maintain IE11 compatibility until we are able to deprecate IE11 support for all of our users.

I hope this helps.

[Snuffleupagus]

We are on very old version (1.7.297) of the pdf.js but it looks like the problematic code is still the same. […] So when you access array using string index, it will look for the index in the string keys and that includes all methods too. This is why when you do widthsByGlyphName['at'] it returns at() method instead of undefined.

Please note that it’s really not advised to use such an “ancient” version of the library; please find the latest releases at https://mozilla.github.io/pdf.js/getting_started/#download

Furthermore, with the changes made in PR #12924 this should no longer happen since widthsByGlyphName is now an Object rather than an Array.

To fix this issue, we are now using Array.find() […] I will do some testing and create a PR for this fix.

As explained above, this has already been fixed and we won’t accept a patch which adds unnecessary overhead here.