Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040417 Firefox/0.8.0+ Steps to reproduce: 1. http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-04-17-09-trunk/ 2. Click the link to mozilla-i686-pc-linux-gnu.tar.gz 3. Ctrl+Y. 4. Watch the progress bar. Result: The progress bar never gets updated, making it look like the download didn't start correctly. The download completes normally; there's just no indication of progress. I have "Show the download manager when a download begins" turned off.

See also bug 240832

This bug is WORKSFORME with a CVS trunk build (20040418) of Firefox on Linux.

I'm seeing this on "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040418 Firefox/0.8.0+"...

Please note that this also happens with the Seamonkey Download Manager on trunk 2004041809/WinXP SP2.

Christian, could any of the recent docloader/uriloader changes have broken progress reporting in the download manager? Apparently this is not just a firefox regression but a seamonkey download manager too.

hmm... possibly... I don't think it's all that likely... I hope to find time to debug this a bit later today

js console shows: Error: gDownloadView.view has no properties Source File: chrome://communicator/content/downloadmanager/downloadmanager.js Line: 167 Error: this.doc.getElementById(aDownloadID) has no properties Source File: file:///C:/Programme/Mozilla/components/nsDownloadProgressListener.js Line: 105

var aDownloadID = aDownload.target.path hm... shouldn't that be targetFile? ah! this is probably fallout from darin's ftp upload patch... (bug 24867) looks like he didn't change nsDownloadProgressListener.js...

nice find Christian!

damn! i think i just forgot to checkin my nsDownloadProgressListener.js changes. that must have been some good stuff i was smoking last week! :-(

patch for nsDownloadListenerProgress.js checked in. however, that file does not seem to be part of firefox, so i don't see how that explains the original bug report.

(In reply to comment #11) > patch for nsDownloadListenerProgress.js checked in. however, that file does not > seem to be part of firefox, so i don't see how that explains the original bug > report. Changing the equivalent forked code in toolkit to match the xpfe changes in that checkin seems to fix the problem in Firefox: http://lxr.mozilla.org/seamonkey/search?string=.target.path

*** Bug 241096 has been marked as a duplicate of this bug. ***

This changes aDownload.target.path to aDownload.targetFile.path in DownloadProgressListener.js and downloads.js, according to the comments in this bug.

Comment on attachment 146613 [details] [diff] [review] Firefox patch, according to comments above Requesting review...

Comment on attachment 146613 [details] [diff] [review] Firefox patch, according to comments above let's get this checked in

(In reply to comment #14) > Created an attachment (id=146613) > Firefox patch, according to comments below > > This changes aDownload.target.path to aDownload.targetFile.path in > DownloadProgressListener.js and downloads.js, according to the comments in this > bug. You missed one (as did my last comment) without changing this one getTypeFromFile throws an exception: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/downloads.js#132 Not sure if there are any others.

Good catch. Thanks.

Comment on attachment 146618 [details] [diff] [review] Revised patch, according to Pike's comment Requesting review for revised patch...

This big has been fix. Works on build 2004042009.

I checked this in to the trunk.

*** Bug 241271 has been marked as a duplicate of this bug. ***

This changes aDownload.target.path to aDownload.targetFile.path in DownloadProgressListener.js and downloads.js, according to the comments in this bug. Patch Did not fix the bug Reported in... Bug 241271 has been marked as a duplicate of this bug. Still no progress bar in Page Save As... Only on some page saves...

(In reply to comment #23) > This changes aDownload.target.path to aDownload.targetFile.path in > DownloadProgressListener.js and downloads.js, according to the comments in this > bug. > > Patch Did not fix the bug Reported in... > > Bug 241271 has been marked as a duplicate of this bug. > > Still no progress bar in Page Save As... Only on some page saves... > You're seeing bug 240367 , which is different from this bug. Downloading an executable (*.exe), for example, shows the progress bar now, where before this fix was checked in it did not. However, bug 240367 is a different issue where the download says it fails, but it still actually works. In fact, there's a patch waiting for review there now.

Seeing this bug with the latest trunk build since at least 2004-12-12 on WinXP, exactly as described in the original bug description. Any filetype will reproduce this bug. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041223 Firefox/1.0+

Old, old bug, but I'm verifying it for posterity: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007080208 Minefield/3.0a7pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre