I added the `contentType` property to our `tabs` module in jetpack (see Bug 775606), and I notice that when a PDF is loaded the contentType returned is `text/html` instead of `application/pdf`. I think it should returns the PDF content type instead, like we have for images (even if we display them in an "Image Viewer" in HTML, document.contentType returns the correct value). I didn't try with all file's type that we could display in the browser through an HTML interface, so I'm not aware if we have the same behavior for other content types.

We return the right type for most things that are handled/converted internally, but pdf.js is in fact converting the PDF to HTML and telling the renderer that the content is text/html, so that's all we know about it. pdf.js could possibly hang some property off the channel that would indicate to the core code that document.contentType should not match the channel's content type.

I think we should do something about it, because otherwise is a bit misleading. Users requested a PDF, the URL shows a the proper PDF URL, and in MDN `document.contentType` says "Returns the Content-Type from the HTTP headers of the document", so the user will expected that the `contentType` will be `application/pdf`, or something like that.

Well, to be fair MDN is just lying here. I'll fix it. ;)

ahahah, let me know then, because I use the exact sentence to document the new property in jetpack. :)

https://developer-new.mozilla.org/en-US/docs/DOM/document.contentType fixed.

By the way, there are plenty of other cases in which the property is misleading at best. Try opening file:/// and examining document.contentType. ;)

Thanks for the fix, I will update the jetpack comments and docs as well. :) About `file:///` it doesn't point to a resource, so it's fine. Let's say, if I point to `file:///foo/bar.gif` and I got something different from `image/gif`, well, okay, that will be a problem. :)

> it doesn't point to a resource Actually, it does. It points to a directory, which exist in fairly specific formats. Internally we first convert the directory data to a specific data format which has its own MIME type and then convert that to HTML....

So, what should be the proper `contentType` of the folder? In our case, it doesn't really matter, as soon as the `contentType` gives the proper results for file's resource; but I'm interested in the topic.

Who knows. The concept of "proper" is pretty vague once you start transcoding things....

With pdf.js becoming the defacto standard, more and more addon developers will be trying to use the MIME type (as PDF). Now, yes I do understand that it'll be technically incorrect to classify the file as pdf, since its renderd as html but then isn't it really misleading ? Especially for addons which may require to interact only with a pdf being renderd by pdf.js , there seems to be no feasible way to do it without diving into low level stuff ?