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.
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. :)
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
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?
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...
Comment on attachment 113950 [details] [diff] [review] patch I was wrong, it seems. This should be good.
Comment on attachment 113950 [details] [diff] [review] patch sr=jag
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
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
(In reply to comment #20) > (From update of attachment 113949 [details] ) > 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.