Official chrome extension outdated

[anmolbyte]

It appears that the official chrome webstore extension by Rob W is outdated. It was last updated in 2019.

[Snuffleupagus]

The Chrome extension is no longer "just" very outdated, but now it's unfortunately also broken for some documents when used in Google Chrome 92.0.4515.107 (and above).

One example of a broken file is https://github.com/mozilla/pdf.js/blob/master/test/pdfs/ZapfDingbats.pdf, which fails to render completely with the following error:

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

The cause of this error is the, fairly recently added, Array.prototype.at() method which was fixed in PR #12924 and is included in PDF.js release 2.8.335 and up.
Also, please note that the very same file renders correctly when opened using https://mozilla.github.io/pdf.js/web/viewer.html, in Google Chrome 92.0.4515.107.

---

While I completely understand that you've not had time to update the extension, it does feel somewhat unfortunate to list in prominently in the README when it's in fact no longer working correctly. (Unless an update can be made "soon", I'd probably suggest that we temporarily remove that link from the README.)

As I recall, from the last time this was discussed in #13117 (comment), you were slightly concerned about the recently added scripting support. Hence please note that you could, quite easily, disable scripting by default for only the Chrome extension (in case that'd help get an updated version out quicker).

/cc @Rob--W

[Rob--W]

This will be one of my priorities this weekend.

[Rob--W]

I did some manual tests with the basic functionality, and caught + fixed two regressions so far:

• Allow customization of theme in Chrome extension + set default theme #13841
• Visually hide br in text selections #13842
  • This is not extension-specific, so I filed an issue at Colored bar appears at the left with multi-line text selections in Chrome #13840 for future reference.

Next tasks:

• Evaluate other issues tagged https://github.com/mozilla/pdf.js/labels/4-chrome-specific
• Disable JS by default.
• Look at the list of 1.1k commits (excluding merge commits) made since the last release of the extension to see if there is anything noteworthy to list in the release notes.
• Clean up code if possible - I'll check the version usage to see what versions we need to support (which I've collected according to https://github.com/Rob--W/pdfjs-telemetry)
• More manual testing.

[Rob--W]

I've done an audit of the new scripting engine and found that it's not unsafe, hence I decided to include it in the build instead. However, the functionality is disabled by default to minimize risk:

• [CRX] enableScripting=false by default in Chrome extension #14004

[Snuffleupagus]

@Rob--W Any updates here, since https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm still shows the old version?

[Rob--W]

I've been trying to get an update through. I'll need to update the store listing and developer account to meet the increasingly stricter requirements for listing an extension. Here is a write-up about a recent terrible experience: https://github.com/Rob--W/stackexchange-notifications/issues/31#issuecomment-919034619

I paused my effort on publishing, by investigating the recent report about the absence of the extension on ChromeOS (#14161). That in turn is blocked on getting a Chrome OS environment. I considered a physical device. Apparently it may be possible to run a VM (https://chromium.googlesource.com/chromiumos/docs/+/HEAD/cros_vm.md), but I have yet to test it.

I don't have as much time as before to dedicate to side projects, so my progress is slow.

[timvandermeij]

Oh no, that does sound like a frustrating experience indeed. Hopefully it will work out better for this extension update, but in any case thanks for carrying on with this!

[LifeIsStrange]

@Rob--W Any update? :)

[stevennyman]

@Rob--W FYI the CloudReady Chromium OS distribution has a pre-made VM image available.

I'm also looking forward to an updated version of the extension; if the Chrome Web Store is causing too many issues for publication perhaps you could try submitting to the Edge Addons store :)

[SamB]

@stevennyman Unfortunately, that probably wouldn't help Chrome users ...

[timvandermeij]

For the time being, since the extension is very outdated now, we've removed a few bits about the Chrome extension in #15452 which can be reverted once the extension is updated again.

[Rob--W]

My next attempt to update the PDF.js Chrome extension is scheduled for the weekend of 15 October.

[Snuffleupagus]

Meanwhile, you can grab a build of this extension here and install manually.

Please let's not advertise an unofficial build here, refer to https://github.com/mozilla/pdf.js#chrome for instructions about building the extension yourself.

[Snuffleupagus]

Any updates here, since it's now been three and a half years since the extension was last updated?

---

In addition to the extension not having been updated for a long time, looking at the git history it also seems to have been a few years since any "significant" development happened in the extensions/chromium/ folder.
Unless the Chromium extension will be updated and actively maintained again, is it meaningful to keep the extension-specific issues open still (or can we WONTFIX them)?

[timvandermeij]

I'm afraid that at this point keeping the extension around does more harm than good. It's extremely outdated, it's broken for some documents and users are filing issues for it that we can't address. If we can't get it updated and maintained anymore, I feel like it might actually be better to remove the extension altogether, even though that would be very unfortunate (but in the end the development focus of the project is Firefox).

@Rob--W As the original extension maintainer, what do you think? Given #13669 (comment) it seems like it will be hard to get it updated again, or has the situation improved on the Chrome web store side?

[stevennyman]

It's worth noting that the extension will probably be automatically removed by Google in a few months anyway as part of their manifest v2 depreciation timeline (though it seems that the exact dates are still under review at this point).

[Rob--W]

I'm going to audit the changes since the last time I looked and if retry submission to the Chrome Web Store tomorrow (Sunday).

It's worth noting that the extension will probably be automatically removed by Google in a few months anyway as part of their manifest v2 depreciation timeline (though it seems that the exact dates are still under review at this point).

While the Chrome Web Store does not support new MV2 submissions, they still allow MV2 extensions (like the current PDF Viewer) to be updated. As long as that works, I will retry to submit an update with MV2.

FYI: The Chrome extension of this project relies on the blocking webRequest API in Chrome, which is not available in MV3. The replacement for blocking webRequest in MV3 is declarativeNetRequest, but that does not offer the ability to implement redirections based on the response header. Follow #15161 if you are interested in subscribing to news about the MV3 version of the extension.

[Rob--W]

I have been analyzing log files (https://github.com/Rob--W/pdfjs-telemetry) to determine which Chrome versions should still be supported (basically to re-evaluate Chrome support as I did before in #9397).

Using the data from March:

• About 1M unique clients (due to anonimization, some clients may be counted twice)
• The majority (60%+) is on the latest stable version of Chrome.
• 98.59% is using Chrome 90+ (Chrome 90 was released exactly 2 years ago, 14 April 2021).
• 98.77% is using Chrome 87+ (Chrome 90 was first released in 11 November 2020).
• Chrome 87 has 0.10% usage.
• Chrome 86 has 0.06% usage.
• Chrome 85 has 0.03% usage.
• Chrome 84 has 0.05% usage.
• Chrome 79 has 0.10% usage.
• Chrome 76 has 0.14% usage.
• Chrome 67 has 0.18% usage.
• Chrome 57 has 0.33% usage.

Cursory testing (checking whether PDF.js loads / displays) shows:

• Chrome 84-: viewer is completely broken, because PDF.js uses assignment operators (e.g. ||=) that are syntax errors when not supported.
• Chrome 84 - 86 : viewer renders, but layout is broken (canvas fills part of the page; toolbar items are squished together), because the inset CSS property is not supported until Chrome 87.
• Chrome 87: seems to render fine.

Based on these observations, I am inclined to drop support for Chrome 86-. Since the latest version would not work for a bit over 1% of the users, it would be best to set minimum_chrome_version to 87.

I'll do more testing and submit patches to drop obsolete code from the extension code.

[timvandermeij]

Sounds good! Given that Chrome 86 is from 2020 already, that seems more than reasonable to me. Moreover, note that we already require Chrome >= 88 for the regular builds; see https://github.com/mozilla/pdf.js/blob/master/gulpfile.js#L82.

[Rob--W]

The updated PDF.js Chrome extension was approved two days ago, and the snapshot of that version is tagged at https://github.com/Rob--W/pdf.js/releases/tag/chrome-3.7.108.

I have set the minimum supported Chrome version to 88 instead of 87 because of rendering bugs (ghosting) observed in 87, likely due to PDF.js minimum support for 88 (as Tim mentioned). The minimum supported Chrome version was bumped to 92 in #16499, so in a future extension update I'd have to re-evaluate whether to raise the version requirement.

Note that presently, there is a significant spike in usage at Chrome version 91 (2.48% in april 2023, 2.42% in may 2023), so I'm not keen on dropping support for these versions just yet. The vast majority of these are running on Chrome OS: From a sample recorded on June, 1st, 1201 (0.25% of all unique clients) were running Chrome 91, and of these 1036 (86%) were running on Chrome OS. Caveat: specific clients can be over-represented in the telemetry when they do not persist extension storage across extension restarts, as the implementation relies on that.

[Rob--W]

I'm closing this issue since the Chrome Web Store now has an updated Chrome extension version of PDF.js. I'll monitor regressions (e.g. #16594) and may publish a new update in the short term if needed.

The largest threat to the future of the PDF.js Chrome extension is the lack of proper API to support MIME-based PDF handling in Manifest Version 3. This is tracked in #15161.

[timvandermeij]

Thank you for your work on this @Rob--W!