Expose PDF.JS as a plugin in navigator.plugins

[lebbe]

Unfortunately I can not seem to find a way to detect if PDF.JS is installed in Opera. It is not listed as a plugin in navigator.plugins. Is there somewhere else I should look?

Similar to this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=840439

[Rob--W]

Take a look at chrome://extensions (or CtrlShiftE if I recall correctly).

[lebbe]

How do I do that with JavaScript?

[lebbe]

I want to, in JavaScript, see if pdf.js is installed, so I can in the web-application I am managing see if my end-users are able to view PDF or not. For instance, for the Adobe PDF Reader you can do something like this (taken from https://github.com/pipwerks/PDFObject):

    function hasAdobeReader(){
            var i,
            n = navigator.plugins,
            count = n.length,
            regx = /Adobe Reader|Adobe PDF|Acrobat/gi;

            for(i=0; i<count; i++){
                if(regx.test(n[i].name)){
                    return true;
                }
            }

            return false;

        }

[Rob--W]

See https://gist.github.com/Rob--W/5c4e017e22a47bf55572 (not tested in Opera, but it should work).

[lebbe]

Thank you! How often will the plugin id renew? As often as the plugin itself is updated?

That is, how stable is it to use this code in a production environment? I see that the opera pdf.js plugin already have two ids. How often do we have to maintain/update this script?

[lebbe]

The "waiting for callback to say whether pdf.js plugin exists" also breaks how @pipwerks https://github.com/pipwerks/PDFObject detect pdf render capabilities in the browser.

There are two use-cases where it is important to know if the browser supports rendering pdf, and whether this is done with pdf.js:

1. We want to load pdf.js as an web-application if it is not installed as a plugin.
2. We want to serve the end-user a pdf form, but not if the plugin used to render pdf is pdf.js.

[lebbe]

Either way. It must be bug that pdf.js is not listed as a plugin in navigator.plugins, right?

[Rob--W]

The IDs will not change. Opera allows installation of extensions that are not hosted in the Opera Addon Gallery, so I also included a test for the extension that is hosted in the Chrome Web Store. The gist that I posted tests whether https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm or https://addons.opera.com/en/extensions/details/pdf-viewer/ has been installed.

PDF.js not being listed in navigator.plugins is not a bug, because PDF.js is not a plugin but an extension.

[lebbe]

Ok, so it is an extension. I see.

What about exposing "application/pdf" as a MimeType in navigator.mimeTypes if pdf.js is installed as an extension? Is the null value i receive when I call navigator.mimeTypes["application/pdf"] a bug or a feature?

[Rob--W]

@lebbe It is difficult, though possible to modify navigator object. However this comes with a small performance impact and may have side effects. Therefore I've decided to not bother with modifying the navigator object, especially because there's an easy way to detect PDF.js.

The gist performs asynchronous detection, but it is probably also possible to make it synchronous, if you really want it.

[lebbe]

All existing sane code out there who does the task correctly of checking whether the browser support rendering of PDFs does this by checking for plugins and mimetypes (ignoring the ugly activex-checking in IE). This means that pdf.js is a false negative in many web sites and applications out there.

[Rob--W]

I have personally not came across a site that broke because PDF.js was not detected. Because of that, and especially because navigator has many lazily evaluated properties, and modification of it may therefore have side effects, I'm not thrilled to insert code that runs on every page that modifies the navigator object. I am willing to revisit this decision if there is a compelling reason to do so, but at the moment I'm favouring the current situation over the alternative one.

[lebbe]

So basically, if you are writing an extension to chromium/opera you don't have the ability to say to the browser "I am able to deal files with MimeType X", and let the browser deal with setting up MimeType etc. Would this be a sane feature request to chromium?

I forked @Rob--W gist and made it synchronous: https://gist.github.com/lebbe/0eedf77e8f7e1449f02e if someone else finding this issue is interested.

[Rob--W]

Currently, HTML5 Chrome extensions cannot present itself as a content handler for a certain MIME-type. There are various feature requests and bug reports on Chromium's issue tracker related to this feature, but it hasn't been implemented yet.

Note that your fork is slightly flawed. It scans twice for the PDF.js extension in the Chrome Web Store (CWS). Once is enough. Further, it always scans for both extensions regardless of the browser, which again is suboptimal. You should only scan for the CWS extension in Chrome, and first the Opera then the CWS extension in Opera. On Sep 17, 2014 7:38 PM, "Lars-Erik Bruce" notifications@github.com wrote:

So basically, if you are writing an extension to chromium/opera you don't have the ability to say to the browser "I am able to deal files with MimeType X", and let the browser deal with setting up MimeType etc. Would this be a sane feature request to chromium?

I forked @Rob--W https://github.com/Rob--W gist and made it synchronous: https://gist.github.com/lebbe/0eedf77e8f7e1449f02e if someone else finding this issue is interested.

— Reply to this email directly or view it on GitHub https://github.com/operasoftware/pdf.js/issues/26#issuecomment-55931072.