240835 - No progress indication in download manager

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Jesse Ruderman]

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.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

See also bug 240832

Comment 2

[Darin Fisher]

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

Comment 3

[Wolf [:wolf]]

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+"...

Comment 4

[Vidar Haarr (not reading bugmail)]

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

Comment 5

[Scott MacGregor]

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.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm... possibly... I don't think it's all that likely...

I hope to find time to debug this a bit later today

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

      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...

Comment 9

[Scott MacGregor]

nice find Christian!

Comment 10

[Darin Fisher]

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

Comment 11

[Darin Fisher]

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.

Comment 12

[PikeUK]

(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

Comment 13

[Adam]

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

Comment 14

[Doug Halamay]

Attachment: Firefox patch, according to comments above

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

Comment 15

[Doug Halamay]

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

Requesting review...

Comment 16

[Scott MacGregor]

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

let's get this checked in

Comment 17

[PikeUK]

(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.

Comment 18

[Doug Halamay]

Attachment: Revised patch, according to Pike's comment

Good catch.  Thanks.

Comment 19

[Doug Halamay]

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

Requesting review for revised patch...

Comment 20

[David Park]

This big has been fix. Works on build 2004042009.

Comment 21

[Ben Goodger (use ben at mozilla dot org for email)]

I checked this in to the trunk. 

Comment 22

[Oleg Sidletskiy]

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

Comment 23

[R Hager]

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...

Comment 24

[Doug Halamay]

(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.

Comment 25

[Tim Rørstrøm]

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+

Comment 26

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

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