377477 - Retrying a canceled download changes the modified name of the file

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Pierre-Francois HUGUES]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

This bug may be related to 367868 but is not quite de same thing.

On a webpage, link to "file-with-a-long.and.ugly.name.foo".

I "save link as" this one, and changes the name to "file.foo".

In the download, manager, I cancel this download (before it's done), and then retry it. It restarts, but saves the file to "file-with-a-long.and.ugly.name.foo" instead of the "file.foo" I chose.

Reproducible: Always

Steps to Reproduce:
1. Download (with "Save link as") a file ("foobar.pdf") and change the target filename if the confirmation windows ("foo.pdf").
2. Cancel the incoming download in the Download Manager
3. Retry this download in the Download Manager
Actual Results:  
The downloaded file will be name foobar.pdf (the original name)

Expected Results:  
The file should have been name foo.pdf as wished by the user.

This bug may be related to 367868 but is not quite de same thing.

Comment 1

[Florian Le Goff]

I can confirm this behaviour on my mac, with the same Firefox build.

Comment 2

[Pierre-Francois HUGUES]

I just tried it on "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20060601 Firefox/2.0.0.3 (Ubuntu-edgy)" : the behaviour is the same.

Comment 3

[Ria Klaassen (not reading all bugmail)]

First regression was between 2005-06-28 06 and 2005-06-28 23 (it triggered the filepicker once more after clicking Retry):
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-06-28+05%3A00&maxdate=2005-06-29+00%3A00

Second regression was between 2005-06-30 09 and 2005-07-01-06 (filepicker stayed away): http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-06-30+08%3A00&maxdate=2005-07-01+07%3A00

Could not find a dependency in the download bugs in these ranges so I assume this is a new bug.

Comment 4

[Ed Lee :Mardak]

Do you still see this problem on a trunk build? I see the problem on Firefox 2.0.0.4, but things are working fine on trunk 2007061704.

Comment 5

[Ed Lee :Mardak]

Fixed with bug 382825, so trunk builds after 2007/06/05 correctly work now.

Comment 6

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

Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007082923 Minefield/3.0a8pre

Comment 7

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

http://litmus.mozilla.org/show_test.cgi?id=4661

in-litmus+

Thanks for the excellent bug report, Pierre, and for helping test Firefox 3!  Keep it coming.

Comment 8

[Glenn Linderman]

This bug has returned! Firefox 102.0.1. I had some files that failed to download. I had given them personally chosen save as file names, which appeared in the download list along with the failed status. Clicking the circular arrow icon to retry from the download list caused the download to be retried, but the original entry in the download list was removed, and a new entry created using the name from the URL instead of the name I had chosen. This is annoying.

Isn't there a regression test for this case, given that it used to happen?