863141 - Firefox 20.0.1 Download behaviour is inconsistent

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[fu510n]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

Download multiple files or various file extensions from several websites over several days


Actual results:

I noticed that the way in which downloads are handled with the new download manager is a bit random, and can't be reproduced reliably, even if downloading the same file multiple times purely for the purpose of trying to reproduce the problem. 

Sometimes whilst downloading a file, the file appears on its own in the downloads folder with it's proper name and extension, other times it will also have an identical copy of that filename with a .part extension added to it, other times there is no .part file, other times there is only the .part file which gets the .part extension removed upon doenload completion, and when there is a .part file created, it is sometimes left behind if a download has been cancelled and the downloads history has been cleared, and other times the part file gets removed after cancelling the download when it still exists in the download history and the retry button is present for that download.


Expected results:

There should be no .part files left over once all downloads have been cleared from the download history, or at least once a particular download has been cancelled and cleared from the download history, and.part files should be always created for every download.

In either case, whichever way the download management is actually programmed to behave (it's unclear at this stage based on observation), the behaviour should be consistent and manually reproducable every time.

Comment 1

[Wayne Mery (:wsmwk)]

mconley, is there a logging option that can help?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> mconley, is there a logging option that can help?

There is a logging function for the UI bit of the download panel (setting browser.download.debug to true will cause messages regarding the panel UI to appear in the console).

However, I think what you're talking about is deeper - part of the toolkit download manager component. Needinfo'ing Paolo who is likely more familiar with that component.

Paolo - is what fu510n is experiencing expected behaviour?

Comment 3

[:Paolo Amadini]

(In reply to Mike Conley (:mconley) from comment #2)
> Paolo - is what fu510n is experiencing expected behaviour?

It is an expected, known issue :-)

It is due to the fact that we have several different code paths for downloads,
and some of them operate asynchronously, while the current Download Manager is
not designed to be asynchronous from the start.

(In reply to fu510n from comment #0)
> Expected results:
> 
> There should be no .part files left over once all downloads have been
> cleared from the download history, or at least once a particular download
> has been cancelled and cleared from the download history, and.part files
> should be always created for every download.

The new JavaScript API for downloads is expected to enforce these properties,
and will probably be enabled in Firefox 26.