display bytes [size] in Status when download is complete

RESOLVED FIXED in mozilla1.5beta

Status

Core Graveyard
File Handling
P2
normal
RESOLVED FIXED
17 years ago
2 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Biesinger)

Tracking

Trunk
mozilla1.5beta

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
it would be useful to show the amount of bytes transferred [file size] when
download is finished. this info would appear in the Status field, along with the
total elapsed time.
(Reporter)

Comment 1

16 years ago
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps: GUI Features → File Handling
(Reporter)

Updated

15 years ago
QA Contact: sairuh → petersen
Created attachment 113949 [details]
screenshot

ok, I have a patch which makes the dialog look like this when the download is
finished

I'll attach the patch in a second
Created attachment 113950 [details] [diff] [review]
patch
taking bug
Assignee: mscott → cbiesinger
Priority: -- → P2
Target Milestone: --- → mozilla1.4alpha
Attachment #113950 - Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Comment on attachment 113950 [details] [diff] [review]
patch

Do we want to report the size of the resulting file?  Or the number of bytes we
actually got off the network (think streaming decompression and such)?
Hmm. Note that comment 0 is not clear on this :)

I vote for the actual filesize, because this is easier to implement, and it's
what I guess users expect (Why did the dialog show 200 KB when the file is
actually 400 KB large?)
On the other hand, as the download progresses we show bytes downloaded off the
network.  So you'll see things like "200kb, 99%" and then "400 kb downloaded".
hmm, you could make an argument for both possibilities I guess.

I propose we make this a pref. *ducks*

just kidding.

I guess it is better to not suddenly jump to a much larger number, then. So I
would store the aCurTotalProgress from onProgressChange in a member variable and
use that in setCompleted?
yeah, that may be better.... I'd try both and see how they look.
all that just for a comparatively rare case...

Do you have an url which sends compressed data?
http://cvs.php.net/co.php/php4/ext/pgsql/pgsql.c?r=1.141&p=1 for example. 
And, er, is onProgressChange sometimes not called?
No idea.  I've never really figured out the whole progress notifications cabal.
sigh... ok... on the url you mentioned, the content length is unknown. that
means that in the end, onProgressChange gets -1 for the progress (for all 4
progresses). which is of course not useful.

I'm more and more inclined to just stay with the attached patch.
Comment on attachment 113950 [details] [diff] [review]
patch

Sorry, no.  We get the same problem with binhex files; there the content-length
off the server _is_ known and is _not_ equal to the filesize on disk.

As in, if we're going to add UI, let's do it in a way that won't get bugs filed
on it immediately...
Attachment #113950 - Flags: review?(bzbarsky) → review-
Comment on attachment 113950 [details] [diff] [review]
patch

I was wrong, it seems.	This should be good.
Attachment #113950 - Flags: review- → review+
Attachment #113950 - Flags: superreview?(jaggernaut)
Target Milestone: mozilla1.4alpha → mozilla1.5beta

Comment 17

15 years ago
Comment on attachment 113950 [details] [diff] [review]
patch

sr=jag
Attachment #113950 - Flags: superreview?(jag) → superreview+
Checking in locale/en-US/nsProgressDialog.dtd;
/cvsroot/mozilla/embedding/components/ui/progressDlg/locale/en-US/nsProgressDial
og.dtd,v  <--  nsProgressDialog.dtd
new revision: 1.8; previous revision: 1.7
done
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
hm, cvs didn't check in the other file before... now done:
Checking in nsProgressDialog.js;
/cvsroot/mozilla/embedding/components/ui/progressDlg/nsProgressDialog.js,v  <--
 nsProgressDialog.js
new revision: 1.31; previous revision: 1.30
done

Comment 20

13 years ago
Comment on attachment 113949 [details]
screenshot

Whose idea was it to duplicate the elapsed time?
(In reply to comment #20)
> (From update of attachment 113949 [details] [edit])
> Whose idea was it to duplicate the elapsed time?

that was not added by this patch. in fact, rev. 1.1 of that dtd already has the
elapsed time in this text, and presumably also has the separate elapsed time
display. I did not check further to find the earlier version of the file.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.