Josh Aas Reporter
	Description • 18 years ago

We couldn't have file icons in the download manager before because they looked terrible. I rewrote the Mac OS X icon decoder so they use proper 8-bit alpha and as soon as that lands we can turn them on.

	Josh Aas Reporter
	Comment 2 • 18 years ago

If you download a file, the icon shows up in the dl manager and everything is fine. However, if you then close the browser and open it again to the download manager, the icon is blank. Ben Goodger suggested that this might have something to do with our download item fading code, that someone the opacity of the icon is not getting adjusted. We need to fix this before we turn on download manager icons.

	Josh Aas Reporter
	Comment 3 • 18 years ago

note to myself or whoever else wants to look at the problem in comment #2, the fade code seems to be in mozilla/toolkit/mozapps/downloads/content/download.xml

	Josh Aas Reporter
	Comment 4 • 18 years ago

Reassigning to Mano as he seems to have some idea of what is going on re: comment #2.

	Mike Connor [:mconnor]
	Comment 5 • 18 years ago

FWIW, I'm good to go on this change, assuming it works correctly.  Icons are shiny!

	Asaf Romano (gone) Assignee
	Comment 6 • 18 years ago

Comment on attachment 220046 [details] [diff] [review]
fix v1.0

a=mconnor over irc to land it for a2 without fixing the old-downloads case.

I will keep this bug open for this issue (target: b1).

	Asaf Romano (gone) Assignee
	Comment 7 • 18 years ago

1.8: Checking in download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.20.2.2; previous revision: 1.20.2.1
done

will do the trunk checkin later.

	Asaf Romano (gone) Assignee
	Comment 8 • 18 years ago

bug 239948 tells me this also might be an issue on WIN32 as well in some cases, so i'm not #ifdefing this for now.

	Josh Aas Reporter
	Comment 10 • 18 years ago

Mano - what does "eek v1.0" fix? It doesn't seem to fix the missing icons when you restart the browser.

	Asaf Romano (gone) Assignee
	Comment 11 • 18 years ago

Josh: did you make in both toolkit/components/ (not just toolkit) and browser/?

	Josh Aas Reporter
	Comment 12 • 18 years ago

I had only built in toolkit/, not toolkit/components/. This does seem to fix the problem. Nice work Mano!

	David Baron :dbaron:
	Comment 13 • 18 years ago

(In reply to comment #7)
> will do the trunk checkin later.

Don't forget, or it'll regress in the next release.

	Josh Aas Reporter
	Comment 14 • 18 years ago

If we could try to get this landed on the 1.8.1 branch by Monday morning that would be great. We are approved by drivers via email.

	Mike Connor [:mconnor]
	Comment 15 • 18 years ago

Comment on attachment 221085 [details] [diff] [review]
eek v1.0

ok, ship it!

	Asaf Romano (gone) Assignee
	Comment 16 • 18 years ago

1.8 branch: Checking in src/nsDownloadManager.cpp;
/cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v  <--  nsDownloadManager.cpp
new revision: 1.53.2.8; previous revision: 1.53.2.7
done

	Asaf Romano (gone) Assignee
	Comment 17 • 18 years ago

trunk:
Checking in download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.23; previous revision: 1.22
done
Checking in nsDownloadManager.cpp;
/cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v  <--  nsDownloadManager.cpp
new revision: 1.64; previous revision: 1.63
done

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 18 • 17 years ago

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007123104 Minefield/3.0b3pre