moz-icon urls with a contentType (but no extension in the file name) show the generic file icon

NEW
Unassigned

Status

()

9 years ago
6 years ago

People

(Reporter: sspitzer, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
moz-icon urls with a contentType (but no extension in the file name) show the generic file icon

On Mac, in 1.9.1, this would show me the application icon for pdf:

moz-icon://goat?size=16&contentType=application/pdf

in 1.9.2, that shows me the generic file icon.

FWIW, I believe Firefox still uses this "goat" trick, see
http://mxr.mozilla.org/mozilla1.9.2/search?string=moz-icon://goat

see bug #397823 for some additional details.

smokey believes this is a regression from bug #489864

Comment 1

9 years ago
apparently moz-icon://goat?size=16&contentType=application/pdf doesn't show nothing, while moz-icon://goat.pdf?size=16&contentType=application/pdf does. Same Problem for other contentType such as video/mp4, audio/mp3.

In FF RSS Reader first url is product (moz-icon://goat?size=16&contentType=application/pdf), which is shown as broken image.
I requested 1.9.2.5 approval on bug 397823, since it will make this bug less bad (you'll get a generic file icon instead of nothing at all).

I did try to fix this bug a while back, too, but my C++ is less than non-existant (iirc, I got far enough that I was talking to the MIME service, but fell down trying to get the MIME service to give me the default file extension for the offered MIME type, which is what we now need to get the icon from the Cocoa icon decoder).
Blocks: 599904
Created attachment 568998 [details] [diff] [review]
Get the icon by first getting the extension for the content-type

Here's a patch that fixes this bug; I happened upon the fix while cleaning up some old stuff.  No guarantees that it's the correct series of GeckXPCOM C++ incantations, though, but it WFM.

It's been ages since I've been able to build the trunk, so the patch is against 1.9.2, but it should be trivial to merge, since aside from the file moving to image/decoders/icon/mac/nsIconChannelCocoa.mm, this part of it hasn't been changed since I fixed bug 397823 back in April of last year.

I offer this patch up in the hope that it's helpful to someone who depends on goats and would prefer not to keep doing the XPCOM gymnastics that have been required to get an icon from a content-type on Mac OS X since the death of nsIInternetConfigService back in June of 2009.
You need to log in before you can comment on or make changes to this bug.