Closed Bug 427978 Opened 15 years ago Closed 15 years ago

Content Type icon is missing

Categories

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

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: bugmozz, Assigned: jimm)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached image 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
Blocks: 415273
Product: Firefox → Core
QA Contact: file.handling → file-handling
Summary: Content Type icon is missing. → Content Type icon is missing
Assignee: nobody → jmathies
Flags: blocking1.9?
pal-moz - does that happen for every entry in the list? Or just some?
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...
(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.
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.
wait a minute, "which only specifies an extension". That seems to rule out GetPrimaryExtension completely.
So I think just assinging fileExt to filePath when it's declared should fix this.
moz-pal, do you have the ability to test applying this to see if it addresses the problem?
er sorry, pal-moz..
Assignee: jmathies → nobody
Component: File Handling → ImageLib
QA Contact: file-handling → imagelib
Assignee: nobody → jmathies
Attached image screenshot
The patch seems to fix the issue.
Attachment #314620 - Flags: review?(pavlov)
Priority: -- → P2
Target Milestone: --- → mozilla1.9
Flags: blocking1.9? → blocking1.9+
Attachment #314620 - Flags: review?(pavlov) → review+
Attachment #314620 - Flags: approval1.9?
Attachment #314620 - Flags: approval1.9? → approval1.9+
Keywords: regression
mozilla/modules/libpr0n/decoders/icon/win/nsIconChannel.cpp 	1.47
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008042705 Minefield/3.0pre ID:2008042705
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.