Pdf.js: Convert PDF.js Firefox add-on to a WebExtension

[Rob--W]

PDF.js has three different build targets: web, Firefox add-on and Chromium extension.

The Firefox add-in is built using legacy add-on technology that will be gone from Firefox 57. Although the Chromium extension can be used in Firefox as-is, doing so would degrade the functionality (compared to the existing Firefox add-on). Mainly, the fact that the URL looks ugly (#6444) and the inability to render PDF resources that are not available via another GET request (e.g. POST, or URLs that expire after one request).

To convert PDF.js to a WebExtension, we need to:

• [ ] Migrate preferences from the preference service to the storage API.
• [ ] Use the i18n API for localization.
• [ ] Integrate in the find bar.
• [ ] Detect PDF network requests, grab the response body, serve the PDF viewer HTML and pass the PDF data down to the page (with sufficient validation at each step to avoid cross-origin information leakage). This feature can be implemented using the API from https://bugzilla.mozilla.org/show_bug.cgi?id=1255894.

The first two are easy, we already use these APIs in the Chromium extension. To send the preferences from the old to the new storage, an Embedded WebExtension can be used.

(this has been reported before, at #8227 and https://bugzil.la/1271476, but there were no concrete implementation plan)

[timvandermeij]

I'm wondering if we actually need to integrate the find bar. The default viewer at https://mozilla.github.io/pdf.js/web/viewer.html does not use Firefox's find bar, but rather our own find bar. I think it is much more useful for us as we have more functionality that the built-in find bar can provide (see #7870 and #7501 among others). Currently, we're unable to resolve those differences because we cannot influence the built-in find bar. If the extension were to use our find bar as well, we would not only have easier code because we do not need to handle two find bars anymore, but it would also allow us to finally implement the behaviour of these patches properly. In other words, for me personally the find bar integration could be left out, which would ease porting to a WebExtension. Perhaps others (UX people?) have a different opinion, though.

I also cannot find anything regarding a WebExtension API for the findbar, and I'm not sure if requesting this API would have much priority given the other APIs that need to be implemented before Firefox 57.

[yurydelendik]

@Rob--W can we perform something simpler just for Firefox, e.g.

1. try to override PDF_VIEWER_PAGE with something extension can provide
2. this URL can be provided via e.g. port created via some createNative (?)

[automatedbugreportingfacility]

Just for the record, to avoid opening a new ticket: the extension is now disabled in Nightly unless the _extensions.legacy.enabled_ preference is set to true (false by default).

[timvandermeij]

How should we prioritize this issue? I understand that the developer add-on may be broken if we don't fix this before Firefox 57, but since that is for development purposes anyway it shouldn't matter too much. I'm more worried about the built-in version, since AFAIK it also makes use of the legacy add-on code. Should we ping someone from the Mozilla core team to assess this, since this may impact PDF.js in Firefox 57?

For components like the fallback bar (which I assume are not available for WebExtensions) we can just make our own and style it like the existing one.

[Rob--W]

PDF.js still works fine as the default PDF viewer in the current Nightly, Firefox 58.0a1.

Firefox's source contains many references to PDF.js internally, so until that is removed (maybe as part of project Mortar?), PDF.js will continue to work as expected in Firefox.

[turtle0x1]

Hi, im embeding PDF's into the web page (not a new tab / window) and it works as epexpected in 55.0.3(32bit) but it doesn't work in developer edition or nightly, I know this is about as vague as I can be so if you need more information just ask !

[Snuffleupagus]

@dhope0000 Please don't post unrelated comments on issues, since that just adds noise to the conversation. If you need assistance, please read https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md before opening a new issue containing all the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md (access to an example and clear steps to reproduce is crucial).

[ExE-Boss]

We could probably use the content handlers API that is being implemented in bug 1457500.

[jscher2000]

Would generating pdf.js pages with an extension allow users to work around the block on content scripts being injected into pdf.js pages in Firefox 60+ (intentional, per bug 1454760)? It is a question of particular interest to users of translation extensions.