Closed Bug 708292 Opened 13 years ago Closed 3 years ago

Allow Firefox add-ons to add a mimetype to navigator.mimeTypes array

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86
Windows XP
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: gerds21, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

In Firefox 6.0.2, I installed the pdf.js add-on. This add-on allows Firefox to display pdf documents.

The pdf.js is described here...
https://github.com/mozilla/pdf.js
http://mozilla.github.com/pdf.js/extensions/firefox/pdf.js.xpi



Actual results:

When the add-on is installed, I examined the navigator.mimeTypes array, and noticed that there was no type "application/pdf" in the array, despite the fact that the browser is now capable of displaying pdf documents.

I am assuming this result is the same for other versions of Firefox as well.


Expected results:

I realize that this add-on is not a plugin, however, I believe it would be good if the "application/pdf" type was allowed to be added to the navigator.mimeTypes array by this add-on.

For one thing, from Javascript you would be able to tell that the browser is capable of displaying pdf documents. This is what happens with the Adobe PDF Reader plugin, which adds the "application/pdf" to the mimeTypes array.

Also, I would point out that the Chrome browser has a native PDF viewer, and it shows up in the navigator.mimeTypes and navigator.plugins array, despite the fact that it is not strictly a plugin that a user can install/uninstall. But it does allow a Javascript coder to determine whether or not a browser can display pdf documents. 

I am asking if you could allow the developers of the pdf.js add-on to add an entry to the navigator.mimeTypes array.

The mimeTypes array issue is being discussed by the pdf.js developers here...
https://github.com/mozilla/pdf.js/issues/891
https://github.com/mozilla/pdf.js/issues/891
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
> For one thing, from Javascript you would be able to tell that the browser is capable of
> displaying pdf documents.

Isn't the test for that to check navigator.mimeTypes["application/pdf"]?  If you get an object, then we can display PDF (internally, via a helper app, whatever)...
That is exactly what I'm getting at.

If you have PDF.js installed as an add-on, but do not have any other PDF reader plugin installed, then the navigator.mimeTypes["application/pdf"] object will NOT exist. But it should exist, at least in my opinion.

Currently, add-ons are not permitted to add a mimetype to the navigator.mimeTypes array. At least, that is what I am told. Only plugins are supposedly allowed to add a mimetype to the array.

I would like navigator.mimeTypes["application/pdf"] to return an object when the PDF.js add-on is installed in Firefox. And to do that, the add-on needs the capability to add a mimetype (ie. the "application/pdf" mimetype) to the navigator.mimeTypes array.
> If you have PDF.js installed as an add-on, but do not have any other PDF reader plugin
> installed, then the navigator.mimeTypes["application/pdf"] object will NOT exist.

Why not?  Doesn't it depend on the exact state of MIME settings?

> Currently, add-ons are not permitted to add a mimetype to the navigator.mimeTypes array.

In what sense?

Plug-ins are the only things that can change its length an its enumerable properties.  But a direct property lookup on navigator.mimeTypes can see types that are not enumerable and that have nothing to do with plug-ins.

> I would like navigator.mimeTypes["application/pdf"] to return an object when the PDF.js
> add-on is installed in Firefox.

Then all that needs to happen is for the MIME service to say that we can handle this type internally (or that we can handle it via a helper app).  The navigator.mimeTypes code already checks for all that.

So the real question is whether what needs changing is the navigator.mimeTypes code (to look at some other data source) or the code of either the MIME service or the addon, or both, to provide data via the data source the navigator.mimeTypes code is already looking at.
(In reply to Eric Gerds from comment #2)
> If you have PDF.js installed as an add-on, but do not have any other PDF
> reader plugin installed, then the navigator.mimeTypes["application/pdf"]
> object will NOT exist. But it should exist, at least in my opinion.
If I install pdf.js, I see "application/pdf" when I execute the following snippet:
 alert(navigator.mimeTypes["application/pdf"].type)
Also, 
 alert(navigator.mimeTypes["xxx/yyy"].type)
throws TypeError.
But navigator.mimeTypes "array" do not contain "application/pdf".

That is, "application/pdf" exists in navigator.mimeTypes but not "enumeratable".
> Also, I would point out that the Chrome browser has a native PDF viewer, and it
> shows up in the navigator.mimeTypes and navigator.plugins array, despite the
> fact that it is not strictly a plugin that a user can install/uninstall.
Technically Chrome internal PDF viewer is only a PPAPI plug-in so it is reasonable that the plug-in is enumerated in navigator.mimeTypes.
I uninstalled all of my PDF readers. Then I installed the latest PDF.js addon v0.2.218 into Firefox 9.0.1 on Windows/XP, and I get navigator.mimeTypes["application/pdf"] == undefined.

However, I have noticed that PDF.js addon now has the capability of displaying PDF documents inside object tags. Therefore I am now able to detect whether the browser can display PDFs or not with this addon. This is the next best thing to having a mimeType in the mimeTypes array.
> and I get navigator.mimeTypes["application/pdf"] == undefined.

Then that's a bug in the add-on.  Do please let them know.
See Also: → 977529
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML

navigator.mimeTypes is now always empty. This is being standardized in https://github.com/whatwg/html/issues/6003.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.