Open Bug 959103 Opened 10 years ago Updated 2 years ago

Download gets duplicated and stuck with a new profile

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect

Tracking

()

People

(Reporter: andrei, Unassigned)

References

Details

Steps to reproduce:

1. Open Firefox with a clean/new profile
2. Go to: ftp://ftp.mozilla.org/pub/firefox/releases/3.6/mac/en-US/Firefox%203.6.dmg
3. Wait for the Save As dialog to open
4. Check the "Save File" radio button
5. Click on "OK"

Expected results:
1 download has been added to the download queue, and is visible in both the Download Panel and the Library Window

Actual results:
The same download is added twice and both are visible in the Download Panel and in the Library Window. The first instance never finishes and can not be canceled or cleared.

If I run this on an existing profile the first Download Item usually finishes.

I have found this while working on a download library as part of our automated Mozmill test suit.

====

This looks like the download starts in the background _before_ I press Ok in the Save As dialog, and when I do press Ok, the Download gets duplicated. The original download remains blocked to where it was at the time of the command to Save it while the 2nd download is the copy to the actual location where it gets saved.

I'm doing a regression range now.
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d136c8999d96&tochange=2ab07dec6404
The pushlog is pretty big, but a likely candidate might be bug 847863.

Paolo or Neil can you please have a look if this is indeed a regression introduced with bug 847863 or maybe from other nsIDownloadManager refactoring into the new Downloads.jsm?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(enndeakin)
Are there any errors you can see in the browser console when this problem appears?
Nothing in the Browser Console.
I don't see this problem with an existent profile and the latest Aurora build. Is it really necessary to have a clean profile? If yes, which preference is causing this problem?
Found it!

The blame seems to rest on `browser.download.panel.shown`.
If this is not set to `true` I see double downloads in both the Panel and in the Library Window

Note that this is not happening 100% of the time while testing manually.
About 50%, maybe higher.

I've seen this on both OSX and Windows 8
No, I don't think that we have the right steps yet. The pref as mentioned above is the one to enable the download panel. If that is really the case there would be no need for a fresh profile. Btw I haven't gotten an answer to my question yet. And I wonder if that problem only occurs if the pref is set to true by default with the first start of the profile or if it also happens with false on first start.
That pref is not the une to enable the panel, it's set after the first time the panel is shown, so sounds like this is a race condition when the absolutely first download is executed with the downloads panel UI.
The pref exists since we open the panel automatically the very first time a download starts.
(In reply to Henrik Skupin (:whimboo) from comment #6)
> No, I don't think that we have the right steps yet. The pref as mentioned
> above is the one to enable the download panel. If that is really the case
> there would be no need for a fresh profile.
Yes, you are right. As I said in comment 5, if I take an existing profile and set the pref 
`browser.download.panel.shown` to false I don't see the buggy behaviour.

> Btw I haven't gotten an answer to my question yet.
I though I have. No fresh profile is needed.

I have just reproduced the issue by:
- clearing the download list (from the Library UI) // not sure if actually needed
- removing the mentioned pref // from about:config
- restarting Firefox // not sue if actually needed
- opening ftp://ftp.mozilla.org/pub/firefox/releases/3.6/mac/en-US/Firefox%203.6.dmg
- checking that Save As is active
- clicking Ok

But I've only seen this 1 out of 10 runs by doing the above-mentioned steps.

> And I wonder if that problem only occurs if the pref is
> set to true by default with the first start of the profile or if it also
> happens with false on first start.
I'll try patching Firefox to have this pref set to true by default to see what happens.
I've build Firefox with `browser.download.panel.shown` set to `true` as a default option.
I've run it 10 times with a new profile and the mentioned issue does not reproduce.
(As a side effect, as expected the Download Panel does not open automatically).

I agree with Marco on what sounds like a race condition.
Basically the Download Panel does not automatically open when the download starts.

The Download Panel only opens when Ok is clicked in the Save As dialog.
The Download starts in the background before that.

So when the panel actually opens the download also shifts from the temporary location to the actual one. This is where things break.
Is this on current Trunk?
(In reply to Marco Bonardo [:mak] from comment #10)
> Is this on current Trunk?

Yes
Can you try to get a log of the problem by setting the "browser.download.debug" preference?
Flags: needinfo?(paolo.mozmail)
I was able to reproduce this. I'll see if I can debug it a bit.
Flags: needinfo?(enndeakin)
Neil, any updates here?
I can still reproduce the problem.
Flags: needinfo?(enndeakin)
Ping Neil re comment 13
I don't know. It was too long ago.
Flags: needinfo?(enndeakin)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.