User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce: Type `navigator.mimeTypes` in console. Actual results: Return a MimeTypeArray that does NOT include 'application/pdf'. Expected results: Return a MimeTypeArray that includes 'application/pdf'.

Hi, Reporter, Sorry for the late reply. Regarding the test steps, could you be more specific? One more question, can you see the pdf support in application page (*1) and mimeTypes.rdf file(*2)? Notes: 1. Type "about:preferences#applications" in url bar, and then type "pdf" in application search bar. 2. Type "about:support" in URL bar, and then open Profile Folder (Show Folder). After Profile folder is opened, please search "application/pdf" in "mimeTypes.rdf" file

The navigator.mimeTypes array does not contain application/pdf. As clear as I can be. :/ 1. Yes, it shows up here as "Portable Document Format (PDF)" and "Preview in Firefox" is the selected action. 2. Yes it appears in the mimeTypes.rdf folder. Below is the entire file. <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Description RDF:about="urn:handler:web:https://30boxes.com/external/widget?refer=ff&amp;url=%s" NC:prettyName="30 Boxes" NC:uriTemplate="https://30boxes.com/external/widget?refer=ff&amp;url=%s" /> <RDF:Description RDF:about="urn:scheme:handler:ircs" NC:alwaysAsk="true"> <NC:possibleApplication RDF:resource="urn:handler:web:https://www.mibbit.com/?url=%s"/> </RDF:Description> <RDF:Description RDF:about="urn:scheme:mailto" NC:value="mailto"> <NC:handlerProp RDF:resource="urn:scheme:handler:mailto"/> </RDF:Description> <RDF:Description RDF:about="urn:root" NC:en-US_defaultHandlersVersion="4" /> <RDF:Description RDF:about="urn:handler:web:https://mail.google.com/mail/?extsrc=mailto&amp;url=%s" NC:prettyName="Gmail" NC:uriTemplate="https://mail.google.com/mail/?extsrc=mailto&amp;url=%s" /> <RDF:Description RDF:about="urn:scheme:handler:webcal" NC:alwaysAsk="true"> <NC:possibleApplication RDF:resource="urn:handler:web:https://30boxes.com/external/widget?refer=ff&amp;url=%s"/> </RDF:Description> <RDF:Description RDF:about="urn:schemes"> <NC:Protocol-Schemes RDF:resource="urn:schemes:root"/> </RDF:Description> <RDF:Description RDF:about="urn:scheme:handler:irc" NC:alwaysAsk="true"> <NC:possibleApplication RDF:resource="urn:handler:web:https://www.mibbit.com/?url=%s"/> </RDF:Description> <RDF:Description RDF:about="urn:scheme:webcal" NC:value="webcal"> <NC:handlerProp RDF:resource="urn:scheme:handler:webcal"/> </RDF:Description> <RDF:Description RDF:about="urn:scheme:ircs" NC:value="ircs"> <NC:handlerProp RDF:resource="urn:scheme:handler:ircs"/> </RDF:Description> <RDF:Description RDF:about="urn:handler:web:https://www.mibbit.com/?url=%s" NC:prettyName="Mibbit" NC:uriTemplate="https://www.mibbit.com/?url=%s" /> <RDF:Seq RDF:about="urn:schemes:root"> <RDF:li RDF:resource="urn:scheme:webcal"/> <RDF:li RDF:resource="urn:scheme:ircs"/> <RDF:li RDF:resource="urn:scheme:mailto"/> <RDF:li RDF:resource="urn:scheme:irc"/> </RDF:Seq> <RDF:Description RDF:about="urn:mimetype:application/pdf" NC:value="application/pdf"> <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetypes"> <NC:MIME-types RDF:resource="urn:mimetypes:root"/> </RDF:Description> <RDF:Description RDF:about="urn:handler:web:https://compose.mail.yahoo.com/?To=%s" NC:prettyName="Yahoo! Mail" NC:uriTemplate="https://compose.mail.yahoo.com/?To=%s" /> <RDF:Seq RDF:about="urn:mimetypes:root"> <RDF:li RDF:resource="urn:mimetype:application/pdf"/> </RDF:Seq> <RDF:Description RDF:about="urn:mimetype:handler:application/pdf" NC:handleInternal="true" NC:alwaysAsk="false" /> <RDF:Description RDF:about="urn:scheme:handler:mailto" NC:useSystemDefault="true" NC:alwaysAsk="false"> <NC:possibleApplication RDF:resource="urn:handler:web:https://compose.mail.yahoo.com/?To=%s"/> <NC:possibleApplication RDF:resource="urn:handler:web:https://mail.google.com/mail/?extsrc=mailto&amp;url=%s"/> </RDF:Description> <RDF:Description RDF:about="urn:scheme:irc" NC:value="irc"> <NC:handlerProp RDF:resource="urn:scheme:handler:irc"/> </RDF:Description> </RDF:RDF>

Hi, Reporter, Oh! I see. I can reproduce your problem by using the test file (mimeTypesArraryTest.html). I can see the "application/pdf" while I tried to list mimeTypeArray on Windows platform but I cannot see any PDF related information in FFx 48 on Ubuntu & Mac OS X platform. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi, Wesly, This seems to be a legacy problem and happens on Linux & Mac OS X platform. I'm not sure if it causes by design. Who is the right person to ask questions?

Thanks William, after discussion team believes this issue is not related to the features we are developing, thus need someone better in this area to help with (which we don't know either). In the mean time team suggests it may be good to check if this is merely a regression, or a bug we have had from day one. @Paolo, do you happen to know who is the person that best for this issue, too? Or any suggestion is appreciated. Thanks! (In reply to William Hsu [:whsu] from comment #3) > Hi, Wesly, > > This seems to be a legacy problem and happens on Linux & Mac OS X platform. > I'm not sure if it causes by design. > Who is the right person to ask questions?

By the way, this problem can be reproduced on Firefox 18. This might be a bug we have had from day one.

NavigatorPlugins.mimeTypes is a Web API specifically related to plugins: https://developer.mozilla.org/en-US/docs/Web/API/NavigatorPlugins/mimeTypes This method is not related to the helper applications or to file handling. We don't expose to the web the list of all the MIME types that can be handled by the system to reduce fingerprinting. For plugins, I think this is the expected behavior and it's unlikely to change, and this bug report does not describe a use case or provide context to understand why there would be a need for this entry. Anyways, moving the bug to the Core :: Plugins component. Maybe Benjamin knows if we can close it or there might be more information we could provide.

christianmemije, can you explain why you expect application/pdf to be there? Is there a specific plugin you have that you expect to handle PDF files? With the switch to GTK3, we've stopped loading some very old plugins which aren't going to work properly. And next year we're going to stop loading all plugins except for Flash, so this bug will definitely be WONTFIX come January. But in the meantime, I might need more information. You can see the set of plugins Firefox currently sees by loading about:plugins and noting the MIME types for each.

I am using a PDF library, PDFObject, that checks if the browser supports PDFs by looking at the mimeTypes array. https://github.com/pipwerks/PDFObject/blob/master/pdfobject.js#L42

Interesting. Chrome appears to implement a dummy plugin for PDF: navigator.mimeTypes['application/pdf'] MimeType {type: "application/pdf", suffixes: "pdf", description: "", enabledPlugin: Plugin}description: ""enabledPlugin: Plugin0: MimeTypedescription: ""filename: "mhjfbmdgcfjbbpaeojofohoefgiehjai"length: 1name: "Chrome PDF Viewer"__proto__: Pluginsuffixes: "pdf"type: "application/pdf"__proto__: MimeType And the HTML spec says that it may do this: 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. Typically such content handlers are provided by third parties, though a user agent can also designate built-in content handlers as plugins. A user agent must not consider the types text/plain and application/octet-stream as having a registered plugin. One example of a plugin would be a PDF viewer that is instantiated in a browsing context when the user navigates to a PDF file. This would count as a plugin regardless of whether the party that implemented the PDF viewer component was the same as that which implemented the user agent itself. However, a PDF viewer application that launches separate from the user agent (as opposed to using the same interface) is not a plugin by this definition. Evelyn, could the team that's working on the PDF viewer look at this?

Sure, will put this bug into our backlog. Could you paste the link of the HTML spec you mentioned here? Thanks!

(In reply to christianmemije from comment #9) > I am using a PDF library, PDFObject, that checks if the browser supports > PDFs by looking at the mimeTypes array. > https://github.com/pipwerks/PDFObject/blob/master/pdfobject.js#L42 christianmemije, I tried PDFObject's demo page on my Firefox 47 and it works well although I didn't see 'application/pdf' in navigator.mimeTypes either. Therefore, I'm curious how this affect your experience. Could you give me a test case or an usage of this library? Thanks!

(In reply to Evelyn Hung [:evelyn] from comment #11) > Sure, will put this bug into our backlog. Could you paste the link of the > HTML spec you mentioned here? Thanks! Oh, and I found since the new implementation we are working on is actually a plugin, so we could see 'application/pdf' in navigator.mimeTypes. Therefore, we could say this issue will be fixed once our patches land into m-c. \o/

(In reply to Evelyn Hung [:evelyn] from comment #12) > (In reply to christianmemije from comment #9) > > I am using a PDF library, PDFObject, that checks if the browser supports > > PDFs by looking at the mimeTypes array. > > https://github.com/pipwerks/PDFObject/blob/master/pdfobject.js#L42 > > > christianmemije, I tried PDFObject's demo page on my Firefox 47 and it works > well although I didn't see 'application/pdf' in navigator.mimeTypes either. > Therefore, I'm curious how this affect your experience. Could you give me a > test case or an usage of this library? Thanks! The problem exists in Firefox 48.0 on Linux.

Hi christianmemije, I see the problem happening on Firefox 48 too. Thanks for the info. However it's not a bug for Firefox 48, instead, I'm thinking it's a side effect of a bug fixing. The difference between 47 and 48 is,'application/pdf' does NOT exist in the Array of navigator.mimeTypes on Fx47 but you can use object key (navigator.mimeTypes['application/pdf']) to get a value. Someone corrected this mismatch on 48. [1] In bug 1144204 we ensure navigator.mimeTypes only returns mimeTypes supported by *plug-ins* therefore 'application/pdf' shouldn't in the return value of navigator.mimeTypes because PDF.js isn't a plug-in. Unfortunately, I don't have a better solution for PDFObject library on how to detect if there is a pdf viewer in the browser. Hopefully this might not be an issue anymore in a later version because we will have an alternative PDF viewer solution, which is a plug-in. [1] Testing page in comment 4 uses Array interface to show all supported mime types, therefore it looks the same on 47 and 48.

(In reply to Evelyn Hung [:evelyn] from comment #16) > Unfortunately, I don't have a better solution for PDFObject library on how > to detect if there is a pdf viewer in the browser. Hopefully this might not > be an issue anymore in a later version because we will have an alternative > PDF viewer solution, which is a plug-in. > Correctness: it's not a plug-in but an add-on. I prefer to keep this bug open so we can revisit here when NPAPI is removed and see how to deal with this case in the new PDF viewer solution.

Hello I'm the author of the PDFObject JavaScript utility https://github.com/pipwerks/PDFObject. (Thanks Christian for starting this thread.) What end users need is a way to determine whether the browser is capable of rendering a PDF within an HTML page. In the old days, inline PDFs were only supported if the browser had a plugin such as Adobe Acrobat (aka Reader) or Foxit installed. Thus, we could search for the PDF MIME type. This has worked for years -- PDFObject has been around since 2009, and has always supported Firefox. Nowadays, most browsers (but not all) have some form of built-in PDF support. I recently overhauled PDFObject to reflect changes in the browser landscape (eg no more ActiveX in Internet Explorer), and as part of my research, I determined the application/PDF MIME type was the only consistent and reliable way to determine native browser support for PDFs across browsers. For example, Firefox now utilizes PDF.js to provide native PDF support, but does not expose PDF.js in a way that enables us to detect its availability. My updated PDFObject code, which relies on application/PDF, was working in the latest version of Firefox when I released it in April 2016 (tested on Mac OS X as well as Windows 8.1 and Windows 10). Then somewhere along the way, Firefox stopped reporting the application/PDF MIME type and PDFObject stopped working in Firefox. Without the ability to check the MIME type, we are left with a bunch of hacks. If we can't perform true feature detection, which is the widely accepted best practice, we are forced to resort to userAgent sniffing and other hacks. E.g. we know Firefox 48 supports PDF.js, so just assume if this is Firefox 48 it will work. Or to try to instantiate the object then use JavaScript to see if it actually worked. Detecting HTML5 video support requires using JavaScript to instantiate a video object then running video.canPlayType. PDF objects have no corresponding 'canPlayType' method to verify the PDF is actually supported. We are left with MIME types. I understand the concern about fingerprinting. If all Firefox users have built-in PDF support, leaving application/PDF MIME intact won't affect fingerprinting because everyone who uses Firefox will have it. As far as discontinuing plugins, from an end-user's perspective, MIME type has never been about plugins, it's about detecting support for a given *feature*. From this perspective, leaving the MIME type intact is simply saying the *browser* supports the PDF MIME type, whether natively or via add-on/extension/plugin. Thank you for helping to resolve this issue. It's very important to a lot of people. There are tens of thousands of PDFObject users -- PDFObject is in NPM and is served via CDNJS, which attests to its wide user base. There are many others who use a similar technique to embed PDFs without the PDFObject utility. All we need is for Firefox to continue to report application/PDF when native PDF support is provided, or some other API method (reachable via JavaScript) which can be pinged to see if the browser is capable of rendering PDFs within an HTML page, similar to how the Video API provides canPlayType. Thanks - philip

Hello, just following up. Any chance we can get application/pdf put back into navigator.mimeTypes, to align with what all other major browsers are doing? Thanks

Just wanted to follow up on this since NPAPI has been removed from ff since v52 I believe and I am also interested in making use of philip's project.