PDF.js is developed as a Firefox extension right now, although it gets packaged directly into Firefox instead of shipping as an extension: https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs It does not look like too much work to turn it into a web extension at this point, in fact there is already a Chrome extension which can be coerced to work in Nightly: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm Once we do this we can no longer use the chrome registration trick to ship it, but we should do it as a system add-on (https://wiki.mozilla.org/Firefox/Go_Faster/Release_Process) instead - this just requires some minor changes to the `moz.build`.

I will list items that we need to watch for: - proper URL in address bar - find bar integration - don't abort initial network stream (some web sites reject second HTTP opened connection as protection) - properties/options->applications integration Printing shall work since mozPrintCallback is part of our web APIs. We might loose warnings when use disabled document fonts and colors, but we can test that other way.

ChromeActions at https://github.com/mozilla/pdf.js/blob/master/extensions/firefox/content/PdfStreamConverter.jsm#L282 contains list of all privileged actions PDF.js is relying on, I see also: - get localization strings - fallback bar display - telemetry - about:config preferences

@yury's points, the counter parts in Chrome (just mentioning in case anyone wants to develop APIs): - The ability to spoof the address bar (so that the PDF URL is displayed instead of the moz-extension: URL), see my proposal and design document at https://groups.google.com/a/chromium.org/d/msg/apps-dev/95IVTx4AiFU/gax8vKlbTD4J - Find bar: No API. - Accessing the original network stream: https://crbug.com/487422 - properties/options->applications integration: None, Chrome does not offer any way to select the application that should handle a MIME type. Whichever extension takes priority (in webRequest handling) is determined by the installation time. The last extension wins.

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

Since this is not currently shipped as a bootstrapped extension, this is not a blocker