152050 - Download manager loses '%' when download is stopped/finished

Status: RESOLVED WORKSFORME

(SeaMonkey :: Download & File Handling, defect)

Description

[Aaron Kaluszka]

Download manager loses '%' in the cell in the '%' column when the download is
stopped/finished.  This might have something to do with where the final data is
being pulled from.  This is demonstrated by the fact that cancelled files with
an unknown download % become '-1' ('-1%' in title bar of download progress
dialog is a different, but related bug).  I couldn't pinpoint the problem, but I
know that the '%' is hard-coded into the progress dialog.  It seems like the
dialog is where download manager gets its data until the download completes. 
This download completion percentage needs to have a % tacked on it unless it is
-1, where 'Unknown' should be displayed.  I don't know why there are two cases
for updating the row, but it seems like they should be consolidated in order to
avoid these inconsistencies.
build 2002061408-trunk

Comment 1

[B. McLean]

I am experiencing the same type of problem with down load manager.  Every since
I have downloaded the new version (Mozilla v1.7.1 for Linux) I have noted that
file transfers are not exceeding 10kB/sec.  I have broadband Internet access,
and transfers average at 155kB/sec.  The older version of Mozilla (v 0.9.1 for
Linux) did not have this problem.
OS: TurboLinux 7.0, Kernel 2.4.18-17, glibc-2.2.4-33

Comment 2

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 3

[Robert Kaiser]

Works for me with the new download manager in SeaMonkey 2.0 Beta 1 and later.