775683 - Return "application/pdf" as document.contentType when a PDF is displayed with PDF.js

Status: NEW

(Firefox :: PDF Viewer, enhancement, P5)

Description

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Matteo Ferretti [:zer0] [:matteo]]

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. :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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....

Comment 9

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[dahal]

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 ?