If the PDF.JS viewer is enabled in Firefox, add an entry to the |navigator.plugins| variable to indicate there is support for viewing PDFs and that the PDF.JS viewer is used. For comparison, Chrome puts this into the |navigator.plugins| variable: { 0: { description: "Portable Document Format", enabledPlugin: Plugin, suffixes: "pdf", type: "application/pdf" }, 1: { description: "Portable Document Format", enabledPlugin: Plugin, suffixes: "pdf", type: "application/x-google-chrome-print-preview-pdf" }, description: "", filename: "PDF.plugin", length: 2, name: "Chrome PDF Viewer" } There is a "user story" by a developer on the mailing list: https://groups.google.com/d/topic/mozilla.dev.pdf-js/Ysbj9Q8tbrQ/discussion

> For comparison, Chrome puts this into the |navigator.plugins| variable: Because their viewer is implemented as a plugin. Our viewer is not.

I believe this is very important for existing applications: An application that relies on PDF forms (which are not supported by pdf.js if I understand that right, https://github.com/mozilla/pdf.js/issues/1459) sadly needs the Adobe Reader plugin enabled and the pdf.js plugin disabled. So the application should be able to display some hint or warning to the user, depending on whether if pdf.js is enabled or not. Without this, silently switching on the pdf.js handler in a Firefox version update will, on the one hand, improve the PDF experience for viewing static PDFs but it will, on the other hand, break the user experience for PDF forms. -Jay

I agree with Jay. This is critical. If using navigator.plugins is not a good way, I want to do something like below. If(typeof(window.PDFJS)!="undefined"){ //some actions } And in addition if I can detect pdf.js's version and build-no, say, by checking window.PDFJS.version or window.PDFJS.buildno, this would be so great.

(In reply to Masatoshi Kimura [:emk] from comment #1) > > For comparison, Chrome puts this into the |navigator.plugins| variable: > Because their viewer is implemented as a plugin. Our viewer is not. I was how *plugin* is defined in the spec and found from the HTML5 spec (current draft version) at http://www.w3.org/html/wg/drafts/html/master/single-page.html#plugins: > The term *plugin* refers to a user-agent defined set of content handlers used by the user agent that can take part in the user agent's rendering of a Document object, but that neither act as child browsing contexts of the Document nor introduce any Node objects to the Document's DOM. For me PDF.JS satisfies this definition of a *plugin*. Therefor it should be added to the |navigator.plugins| list. Also, if we don't add PDF.JS to |navigator.plugins| this implies if we eventually add a Flash implementation like Shumway to Firefox, there is also no entry for flash exposed in |navigator.plugins|. That means we break all websites that check for Flash beeing available. Breaking these pages feels wrong to me, which is why I would add an entry to |navigator.plugins|. In the case of Chrome and Safari, the viewer isn't a plugin but build into the browser - you don't have to provide anything to "plug in" as a PDF content viewer like Adobe Reader does for Firefox. Still they expose their PDF compability in the |navigator.plugins|.

(In reply to Julian Viereck from comment #4) > > The term *plugin* refers to a user-agent defined set of content handlers used by the user agent that can take part in the user agent's rendering of a Document object, but that neither act as child browsing contexts of the Document nor introduce any Node objects to the Document's DOM. > > For me PDF.JS satisfies this definition of a *plugin*. Therefor it should be > added to the |navigator.plugins| list. Our viewer will introduce child browsing contexts and Node objects because it converts PDFs to HTML5 documents. > In the case of Chrome and Safari, the viewer isn't a plugin but build into > the browser I don't know about Safari, but Chrome PDF Viewer is implemented as a PPAPI plug-in whose filename is pdf.dll on Windows. You can technically even copy the file to any Chromium-based browsers (putting a legal matter aside). It is nothing but a plug-in. That said, I agree it would be reasonable to add a navigator.plugin entry for compatibility even if our implementation is not a genuine plug-in.

(In reply to Jay from comment #2) > I believe this is very important for existing applications: An application > that relies on PDF forms (which are not supported by pdf.js if I understand > that right, https://github.com/mozilla/pdf.js/issues/1459) sadly needs the > Adobe Reader plugin enabled and the pdf.js plugin disabled. So the > application should be able to display some hint or warning to the user, > depending on whether if pdf.js is enabled or not. Our viewer will display a infobar and "Open With Different Viewer" button if the PDF contains a form. So you don't have to display something on your own.

(In reply to Masatoshi Kimura [:emk] from comment #5) > > Our viewer will introduce child browsing contexts and Node objects because > it converts PDFs to HTML5 documents. We add node elements from PDF.JS for sure, but I hope we don't make these nodes "visible" to the web page. This is important in the background of using PDF.JS as an embed. Assume there is an embed that uses a PDF file and this make Firefox load PDF.JS. Assume future that the HTML markup of PDF.JS is exposed to the content outside of the embed. Then if a developer queries for a node of PDF.JS, he will get a match. But to me this seems wrong, because then the site's behavior depends on the PDF viewer used. Note sure if the Brendan and Yurys plan as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=738967#c25 will take care of this, so I raise my hand here to point out that we might run into trouble here.

(In reply to Masatoshi Kimura [:emk] from comment #5) > > That said, I agree it would be reasonable to add a navigator.plugin entry > for compatibility even if our implementation is not a genuine plug-in. :Yury, should the "Importance"-flag of this bug be changed given the above statement?

@Masatoshi Kimura, two thoughts here: (1) We do have to tell the user that he or she should use the "Open With Different Viewer" button. Because the PDF form that opens with the PDF.js looks fine at first sight. The user only later notices that something doesn't work form fields if he or she tries to continue. (2) AFAIK, the "Open With Different Viewer" opens the PDF document in a new standalone Adobe Reader, outside the Firefox context. That will not work for PDF forms that are designed to post their form data back to the very server where they were served from, ie from inside the browser context. So the only way make this kind of form work is to have it open inside the browser and that will only work if the PDF.js handler is disabled. –Jay

(In reply to Julian Viereck from comment #8) > (In reply to Masatoshi Kimura [:emk] from comment #5) > > > > That said, I agree it would be reasonable to add a navigator.plugin entry > > for compatibility even if our implementation is not a genuine plug-in. > > :Yury, should the "Importance"-flag of this bug be changed given the above > statement? Not sure if I shall decide that. Please provide examples of navigator.plugin entry usages.

This is important for as. See https://github.com/roundcube/roundcubemail/blob/master/program/js/app.js#L6627 for sample usage. This is how we detect PDF support. I saw such code in other projects.

At least for now, you might try this to detect PDF.js... http://www.pinlady.net/PluginDetect/PDFjs/ This detector is not guaranteed to work forever, as there is no official API (yet) to detect PDF.js.

No progress on this feature request?

The support for doing this in gecko will be landing in bug 558184, we can use this bug for moving pdf.js to the new API

Hi all Sorry for opening an old thread, but was this resolved? There is an active thread related to this topic: https://bugzilla.mozilla.org/show_bug.cgi?id=1293406 Until around August of 2016, Firefox was reporting application/PDF in the mime type array, which enabled scripts like PDFObject to function correctly. Since then, the mime type has been removed, despite PDF.js being available. Without a mime type or an API to let users programmatically detect support for PDF.js, we have no way of updating utilities like PDFObject to properly support Firefox's PDF.js implementation. Thanks

Benjamin and Yury, should Firefox advertise PDF.js or PDFium in navigator.plugins and navigator.mimeTypes? Both Chrome and Edge advertise PDF support in navigator.plugins and navigator.mimeTypes, but Firefox 52+ only advertises Flash.

Yes, see bug 1293406 for better details.

(In reply to Chris Peterson [:cpeterson] from comment #16) > Benjamin and Yury, should Firefox advertise PDF.js or PDFium in > navigator.plugins and navigator.mimeTypes? Both Chrome and Edge advertise > PDF support in navigator.plugins and navigator.mimeTypes, but Firefox 52+ > only advertises Flash. By it's nature PDF.js is not a NPAPI plugin (at least there was no decision made to advertise it as a such) -- it's more like a view for the application/pdf content similar e.g. to a RSS feed viewer. That said, it will be nice to get a feel where we draw the line between something that is a plugin (per w3c term) or just a regular web content (e.g. images, audio). AFAIK PDF.js can add entry to the plugins using fake plugin API (bug 1178963) to address this issue if we decide to do so.