Convert PDF.js Firefox add-on to a WebExtension

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)

[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.

[ExE-Boss]

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