display bytes [size] in Status when download is complete

RESOLVED FIXED in mozilla1.5beta


Core Graveyard
File Handling
17 years ago
2 years ago


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



Firefox Tracking Flags

(Not tracked)



(2 attachments)



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.

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


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

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

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

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]

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]

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]

Attachment #113950 - Flags: superreview?(jag) → superreview+
Checking in locale/en-US/nsProgressDialog.dtd;
og.dtd,v  <--  nsProgressDialog.dtd
new revision: 1.8; previous revision: 1.7
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  <--
new revision: 1.31; previous revision: 1.30

Comment 20

13 years ago
Comment on attachment 113949 [details]

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.