1711615 - Inconsistent behaviour in Download Manager

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Gilbert Benoit]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.7.1

Steps to reproduce:

1. Initiate file download.
2. Download fails (either cancelled, or server failure)
3. Initiate same download again. Successful.
4. Remove entry for failed download from the Download Manager.

Actual results:

The downloaded file was deleted.

Expected results:

Removing the entry from the Download Manager should not affect the file. If the initial download succeeds, then the file is not removed (i.e. correct behaviour). The problem only occurs if the initial download failed. As far as I know, this used to work correctly before the recent changes to the Download Manager (i.e. this is a new problem).

Comment 1

[Dmitry Butskoy (:buc)]

Reproduced under CentOS-7.

After one failed and one successful downloads an attempt to remove one of the two entries (either for failed or for successful) leads to removing of both entries and removing the downloaded file.

Under SM-2.49.5 only one entry (the chosen) is removed and file is not removed.

Comment 2

[Frank-Rainer Grahl (:frg)]

Can someone test with a recent Firefox. Smells like Bug 1601904 which was only recently fixed and so should still be a case for current 89.

Comment 3

[Dmitry Butskoy (:buc)]

Seems OK with the recent FF-78.

The same behaviour with Fx compiled over the 2.53.5 source (despites it seems to use another code for this stuff).

Under Firefox esr78, the both entries are removed from the list, but the downloaded file still exists.

Comment 4

[Gilbert Benoit]

This is much better, but ideally only the specific entry should be removed from the list (that is how it used to work, and that is the correct behaviour).

Comment 5

[Dmitry Butskoy (:buc)]

Seems the same, bug #1501277

Comment 6

[Dmitry Butskoy (:buc)]

Well, the correspond commit from bug #1501277 applies clean (offsets etc. only). No more issue then, the behaviour now matches Firefox (at least esr78).

Comment 7

[Dmitry Butskoy (:buc)]

Attachment: DownloadCore-1711615.patch

Preliminary patch.

Gilbert,

You can try it just against omni.ja:modules/DownloadCore.jsm without need to recompile.

Comment 8

[Frank-Rainer Grahl (:frg)]

I put both mentioned bugs in todays 2.53.9b1 pre. Should be available in the next hours. I think the later bug from Fx 90 still needs some work. Under Windows it still tries to delete the .part file being downloaded by the seocnd transfer. Looking at the program flow not 100% unexpected but I think it is because the code tries to remove both downloads so a different problem. Wonder why it works for Fx or this time a real problem with the download manager.

Comment 9

[Gilbert Benoit]

Tested in SeaMonkey 2.53.9

Problem solved.

Comment 10

[Frank-Rainer Grahl (:frg)]

Lets close. Fixed by backports so nothing in this bug.