Closed Bug 427978 Opened 15 years ago Closed 15 years ago
Content Type icon is missing
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
Product: Firefox → Core
QA Contact: file.handling → file-handling
Summary: Content Type icon is missing. → Content Type icon is missing
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
The patch seems to fix the issue.
Flags: blocking1.9? → blocking1.9+
Status: NEW → RESOLVED
Closed: 15 years ago
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.