User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 When crashing downloads datasource is not cleared, so download manager shows outdated things. Reproducible: Didn't try Steps to Reproduce: 1. start a number of downloads 2. crash firefox, while incomplete downloads exist 3. restart FF, open DL-Manager 4. It contains a list of incomplete downloads (shown incorrectly as download in progress) 5. cleanup downloads 6. cancel a download Actual Results: the download item disappears Expected Results: the item should not dissapear and should enter a state where retry is accessible. Or: automatically restart (or better resume) the broken downloads. When retry is available available and clicking retry it opens a file picker. Expected result is either 1. use the stored filename for retry (preferred) 2. prompt using the "old" directory AND filename Invoking the idea of in the DM context menu "retry" "retry to different location" "retry all" "cleanup completed" "cleanup cancelled" "cleanup all" "delete file" "launch when complete" // when using save as

Resuming interrupted downloads (across sessions) is covered in bug 230870. *** This bug has been marked as a duplicate of 230870 ***

The main key of this bug is not the resume, but the behaviour that an item is cleared out of the list when cancel is clicked. Can't find this in description of bug 230870.

Well, the first line of your report reads: > When crashing downloads datasource is not cleared, so download manager > shows outdated things. Bug 230870 would make it so that the download is resumed from the place where it was stopped (instead of displaying an outdated state). This obviously solves your problem, as you yourself stated in your report: > Or: automatically restart (or better resume) the broken downloads. Regarding the behaviour of Cancel on downloads interrupted by a crash: This WFM as long as the download state is displayed correctly. You are right that this does not work correctly when the download is incorrectly marked as still in progress after a crash, but this will be fixed as well as soon as the correct state is restored after a browser restart (see above). So I still say that this request is a dup of 230870.

Ok. I agree that if the other bug is solved my bug probably is solved too. But how long does it take to fix the other bug, which is indeed more an additional feature (resume)? If you think resume will come in not to far future (before FF2.0) then I agree this is dup of bug 230870.

Bug 230870 should make Firefox 3. Marking duplicate.