381803 - two files are listed in DM, while downloading one file.

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[pal-moz]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070523 Minefield/3.0a5pre ID:2007052316 [cairo]

range, http://hourly-archive.localgho.st/win32/20070523_1627_checkins.html

screenshot, http://img479.imageshack.us/my.php?image=dmon4.jpg

Comment 1

[Dave Townsend [:mossop]]

I saw this before bug 381538 was fixed.

Comment 2

[Hideo Oshima]

Bug 381538 has been fixed but this bug isn't solved yet.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070524 Minefield/3.0a5pre

Comment 3

[Shawn Wilsher :sdwilsh]

Alright, so looking into this, I am fairly certain it is a race-condition situation.  Basically, the database can be updated before we look up the downloads in the window, then we look up the downloads and add them all, and then we get the dl-start notification.  This wasn't an issue before because we relied solely on our rdf datasource to display the UI elements.

So, I have an easy fix if this is the case, but I'd like to see if I can confirm my findings.  I'm having a terrible time reproducing this, so if you do reproduce it, kindly do the following:
1) Open up the DOM Inspector
2) Go to File->Inspect Chrome Document->Downloads
3) Search for downloadView (by id)
4) Make sure View->Show Anonymous Content is selected
5) Expand the richlistbox's children until you get to items that are "download"

What I need from this is the id of the two downloads that are the same.  I suspect that they are also the same, and that's why one doesn't get updated.  If someone can back with me on this (before I can reproduce it), I can confirm my beliefs about this being a race condition, and get an easy fix made up for it.

Comment 4

[pal-moz]

(In reply to comment #3)

same id.
screenshot, http://img128.imageshack.us/img128/4227/dmvi5.jpg

Comment 5

[Shawn Wilsher :sdwilsh]

Attachment: v1.0

What happens is that it gets added to the database before dispatching dl-start.  This is because I moved the dl-start notification in Bug 380250 because when we dispatched it in the past, it hadn't actually started.

Alternatively, I can modify the query to not select downloads that have a status of nsIDownloadManager::DOWNLOAD_NOTSTARTED.  I'm not so sure I like that approach, however.

Comment 6

[Hideo Oshima]

I tried the patch(attachment 266121 [details] [diff] [review]).
It seems good to fix the problem.

Comment 7

[Shawn Wilsher :sdwilsh]

Checking in toolkit/mozapps/downloads/content/downloads.js;
new revision: 1.59; previous revision: 1.58

Comment 8

[-fullmetaljacket-]

VERIFIED

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070531 Minefield/3.0a5pre ID:2007053120 [cairo]