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

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Seth Spitzer]

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

[Fabio]

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.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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