427978 - Content Type icon is missing

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P2)

Description

[pal-moz]

Attachment: screenshot

OK: 20080404_0123_firefox-3.0pre.en-US.win32.zip
NG: 20080404_0254_firefox-3.0pre.en-US.win32.zip

[bonsai]
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1207297380&maxdate=1207302839

Comment 1

[Jim Mathies [:jimm]]

pal-moz - does that happen for every entry in the list? Or just some?

Comment 2

[[e-mail]]

So, the reason the extension was extracted into the file path was because it's used as the fallback if no file or content type is available...

Comment 3

[[e-mail]]

(In reply to comment #1)
> pal-moz - does that happen for every entry in the list? Or just some?
It happens for any moz-icon: which only specifies an extension.

Comment 4

[Jim Mathies [:jimm]]

Hmm, either GetPrimaryExtension is failing for the contentType, in which case in the past we would just use fileExt (but now use an empty defFileExt), or it's returning a different extension for defFileExt that doesn't point to the application in question. The first seems more likely.

Comment 5

[Jim Mathies [:jimm]]

wait a minute, "which only specifies an extension". That seems to rule out GetPrimaryExtension completely.

Comment 6

[Jim Mathies [:jimm]]

So I think just assinging fileExt to filePath when it's declared should fix this.

Comment 7

[Jim Mathies [:jimm]]

Attachment: app pref icon fix v.1

moz-pal, do you have the ability to test applying this to see if it addresses the problem?

Comment 8

[Jim Mathies [:jimm]]

er sorry, pal-moz..

Comment 9

[TimoT]

Attachment: screenshot

The patch seems to fix the issue.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

mozilla/modules/libpr0n/decoders/icon/win/nsIconChannel.cpp 	1.47

Comment 11

[Carsten Book [:Tomcat]]

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008042705 Minefield/3.0pre ID:2008042705