291369 - DM loses EXE icons after new file is downloaded

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Mike Pesce (:By-Tor)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421 Firefox/1.0+

After downloading an EXE file, then downloading another file, the EXE file's
icon returns to the system icon. 

Reproducible: Always

Steps to Reproduce:
1. Download an executable file
2. Download another file type
3.

Actual Results:  
Afterwards, the executable's icon will be lost as it gets pushed down the list.

Expected Results:  
The icon should be remembered.

Comment 1

[Mike Pesce (:By-Tor)]

Attachment: Screenshot

Comment 2

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050421
Firefox/1.0+

confirmed

->NEW

Comment 3

[Jaime Mitchell (use [e-mail] for email)]

Also present in 1.0.3.

Also,

4. Close Firefox 
5. Start new session
6. Return to download manager 

Missing exe icons have reappeared.

Just closing Download manager and reopening is not sufficient.

7. Download another file

Previous session exe files icons do not disappear. 

Comment 4

[Caleb]

I got the same problem (icon for EXE not appearing) by:

1. Starting a download for a .mov file
2. Starting downloading an EXE

Once the EXE finishes first, its icon still remains the "generic" windows
application icon.

Comment 5

[Mike Connor [:mconnor]]

minusing, will take patch.

Comment 6

[Caleb]

Here's some info for the devs out there (I'm trying to solve this one myself):

The problem with applications is that when download starts, it (the exe) gets
assigned with a generic windows application icon which points to
moz-icon://FILE_PATH?size=32.

When the download ends, that path _should_ point to the updated exe icon, but it
gets cached, even though the xul:image has a validate="always" property.
This is probably being cached elsewhere (I'm a newbie so I have no clue).

To workaround this, the code sets the path of the icon to
moz-icon://FILE_PATH?size=32&contentType=CONTENT_TYPE and this seems to work
.... until a non-application is downloaded.

To easily reproduce, repeat this from 1 to N times (start with a clean cache):
 1. Download an EXE
 2. Download a non EXE

Once the non EXE gets added to the DM, the EXE's icon becomes generic again.

I believe that this is the effect of the cache... now if only I knew how to
update the cache with the new application's image!

Comment 7

[Caleb]

Clearing the cache may seem like a nice solution, but looking again at the DM
with the DOMi I can see that when that second download starts, the EXE's icon
starts pointing back to moz-icon://FILE_PATH?size=32 (which has the generic icon).

Going to investigate some more...

Comment 8

[Caleb]

I think a viable solution would probably checking the state of each download
from C++ (nsDownloadManager.cpp), if it's percentComplete is 100 then set its
icon to moz-icon://etc..?size=32&contentType=bleh

To be honest, I don't see why we need to calculate the content type and add it
to the URI, when we can add absolutely anything that does not require any
processing (something like moz-icon://etc..?size=32&done).

Feel free to post patches.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

I still see this, even with the Download Manager front/back-end rewrite.

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Correct behavior observed on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

WFM by comment 10.  Please reopen if you see this on trunk.