User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150305021524 Steps to reproduce: Firefox Mobile always reports that a particular object is in navigator.mimeTypes, no matter what MIME type you actually search for. I have an application that does real-time PDF previews, but I have to write special code for Firefox Mobile only: function detectPDFPreviewSupport() { showpreview = false; // Safari and Chrome have application/pdf in navigator.mimeTypes if (navigator.mimeTypes["application/pdf"] != undefined) { showpreview = true; } // Firefox desktop uses pdf.js, but not mobile or tablet if (navigator.userAgent.indexOf("Firefox") != -1) { if ((navigator.userAgent.indexOf("Mobile") == -1) && (navigator.userAgent.indexOf("Tablet") == -1)) { showpreview = true; } else { showpreview = false; } // have to reset it, as FF Mobile application/pdf listed, but not supported (wtf?) } } Actual results: < 'application/pdf' in navigator.mimeTypes; > true (this is not true, Firefox Mobile does not natively support PDF) < navigator.mimeTypes['blah/foo'] > MimeType { description: "", enabledPlugin: null, suffixes: "", type: "blah/foo" } "blah/foo" isn't actually a real MIME type. Oh no! Expected results: Firefox (Desktop), as well as other desktop and mobile browsers behave properly. Here is the output from Firefox (Desktop): < 'blah/foo' in navigator.mimeTypes > false < navigator.mimeTypes['blah/foo'] > undefined Similarly, here is the output from Chrome (Mobile), which also behaves as expected: < navigator.mimeTypes['application/pdf'] > undefined < 'blah/foo' in navigator.mimeTypes > false < navigator.mimeTypes["blah/foo"] > undefined

This breaks a nasa.gov page as reported in https://webcompat.com/issues/1984

See http://hallvord.com/temp/moz/bug/wc1984.htm for a crazy demo - will also attach it here.

James, any idea why this happens?

Strange. I can reproduce it here too, but not on desktop. I'll dig deeper.

OK, I figured this out. We always count the Android chooser as an option for any mime type, so any mime type could be "handled". Whether that's right or not could be argued I guess, but that's why we have this behavior.

Right. We should stop doing that. On Desktop most of us have another application capable of opening *.docx but it doesn't mean we advertise support for it in navigator.mimeTypes.

It seems that navigator.mimeTypes is not part of any spec. Do we know exactly what it is supposed to represent? Is it mime types that the browser itself can handle, or the system as a whole? We can easily remove the chooser shenanigans.

navigator.mimeTypes is part of HTML spec, https://html.spec.whatwg.org/#navigatorplugins

Ah, so it's specifically supposed to be mimetypes that *plugins* support? We can most likely always return a false result then.

well, looks like browsers behave differently. Would be worth to test different browsers, both desktop and mobile

I guess we should change Gecko to follow what other browsers do. But isn't still clear to me why desktop works on that page and mobile doesn't.

(In reply to Olli Pettay [:smaug] (expect slower than usual review time for couple of days) from comment #11) > I guess we should change Gecko to follow what other browsers do. > But isn't still clear to me why desktop works on that page and mobile > doesn't. The reason is because Android has a default handler for any mime type, representing the Android activity chooser. Desktop has no such thing, but will return valid results for things like 'application/pdf' if you have a PDF viewer installed. I actually think the best thing to do here is to remove the chooser as a default handler, and just query the system for the mime types directly.

and I think we should just follow the spec, so deal with plugins only.

> On Desktop most of us have another application capable of opening *.docx but it doesn't mean we advertise > support for it in navigator.mimeTypes. Actually, we probably do. For example, navigator.mimeTypes["application/msword"] returns a thing for me, on desktop. I think I agree with Olli here, but we should check what other UAs do. Chrome and Safari seem to only return plug-in stuff here. What does IE do?

I guess IE at least has undefined for navigator.mimeTypes["text/html"].

(In reply to Boris Zbarsky [:bz] from comment #14) > > *.docx ... in navigator.mimeTypes. > > For example, > navigator.mimeTypes["application/msword"] returns a thing for me, on desktop. Interesting - so what does navigator.mimeTypes["application/msword"].enabledPlugin return? I have no such mimeType registered in my Firefox so I assume that some Word/MSOffice viewer plug-in has snuck into your instance.

> navigator.mimeTypes["application/msword"].enabledPlugin Returns null, of course. ;) > I have no such mimeType registered in my Firefox Try navigator.mimeTypes["text/html"]? Also, what happens if you try to actually open an application/msword thing? Is an application suggested in the dialog that comes up? > so I assume that some Word/MSOffice viewer plug-in has snuck into your instance Most definitely not.

Comment on attachment 8732690 [details] [diff] [review] Stop returning things for non-plug-in MIME types from the navigator.mimeTypes getter > nsMimeType::GetEnabledPlugin() const > { >- if (!mPluginElement || !mPluginElement->PluginTag()->IsEnabled()) { >+ if (!mPluginElement->PluginTag()->IsEnabled()) { I wouldn't mind keeping the null check just for the sake of missing unlink

(In reply to Boris Zbarsky [:bz] from comment #19) > > navigator.mimeTypes["application/msword"].enabledPlugin > > Returns null, of course. ;) Raises an interesting question: if you at some point did have a plugin that told Firefox it would handle application/msword, and the plugin is no longer installed - what happens to navigator.mimeType? Is it "live", or more like a DB that remains cluttered when a plugin is uninstalled? Not something I have time to research right now.. > > I have no such mimeType registered in my Firefox > > Try navigator.mimeTypes["text/html"]? Also, what happens if you try to > actually open an application/msword thing? Is an application suggested in > the dialog that comes up? If I download Word-documents, Fx suggests LibreOffice. I checked the MIME type, it's correct. > > so I assume that some Word/MSOffice viewer plug-in has snuck into your instance > > Most definitely not. Never ever? What happens on a clean profile? ;) Anyway, I'm sure you agree in principle that it's somewhere between unpractical and undoable to really create a mimeTypes entry for every single file type some software on the machine can handle - not to mention that it would be a bad fingerprinting risk..

> and the plugin is no longer installed - what happens to navigator.mimeType? We basically cache the info in MimeTypeArray on a per-page basis. So if you uninstall (or just disable), the value of .enabledPlugin will go null, afaict, but the entry will still be there for that page. A new pageload should get a MimeTypeArray without that entry. > If I download Word-documents, Fx suggests LibreOffice. I checked the MIME type, it's correct. Huh. Weird... > Never ever? What happens on a clean profile? ;) In a clean profile, on Mac, in the console: navigator.mimeTypes["application/msword"] MimeType { description: "", enabledPlugin: null, suffixes: "", type: "application/msword" } > I'm sure you agree in principle that it's somewhere between unpractical and undoable to > really create a mimeTypes entry for every single file type some software on the machine can handle Well. The non-plugin ones are created lazily when you ask via the named getter and we find that either the OS has an application registered for the type or we do in mimeTypes.rdf. Otherwise the Android behavior would be totally impossible. But I certainly agree we should drop the non-plugin bits from the list here. I mean, I wrote and landed a patch to do that.... ;)

Would it be worth uplifting this patch to ship it sooner? As far as I can tell, all versions back to at least 36 are affected.

That's a call for the Android folks to make. If we _do_ uplift, I think we should uplift Android-only. The risk does not justify the (nonexistent) reward for other platforms.