Closed
Bug 70859
Opened 24 years ago
Closed 23 years ago
Saving page gives "NaN:NaN" as elapsed time
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.6
People
(Reporter: mozilla-06, Assigned: law)
References
()
Details
(Keywords: helpwanted, regression)
Attachments
(1 file)
(deleted),
patch
|
law
:
review+
bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.9) Gecko/20010303
BuildID: 2001030308
If I save a page (e.g. the Mozilla start page), the download dialog displays
"NaN:NaN" as the elapsed time.
Reproducible: Always
Steps to Reproduce:
1. Visit any URL, e.g. the Mozilla site.
2. Press CTRL+S to save or use the file menu.
3. Enter file name
Actual Results: Download dialog with "NaN:NaN" as the elapsed time.
Expected Results: The Dialog should display the elapsed time in number form.
This behavior is rather new and not theme specific. I don't know if this is
influenced by the connection speed (I'm on a 768k ADSL line).
Reporter | ||
Comment 2•24 years ago
|
||
This only happens on HTML pages, not on binary content or FTP sites. The exact
text is:
"Download complete (elapsed time was NaN:NaN)"
Comment 4•24 years ago
|
||
hrm, cannot repro this using 2001.03.05.09 opt comm bits on winnt. is this still
a problem for you?
Reporter | ||
Comment 5•24 years ago
|
||
This still is happening for me on 2001030620 on Win2k.
Comment 6•24 years ago
|
||
seems to be limited to win2k, then? terri also sees this.
bill, i cannot remember if you have win2k, but d'you see this?
Keywords: pp
I do have Win2k; I haven't seen this. I do have another bug.
My theory is that if the download completes fast enough (before the dialog
appears), then this happens.
Reporter | ||
Comment 8•24 years ago
|
||
That makes sense. I usually get this bug with disk cache + memory cache turned
on. With both caches turned off, I get 00:00 as elapsed time for saving.
Comment 9•24 years ago
|
||
bill, what's the other bug you have on this? i'll go ahead and dup it if it's appropeiate. thx!
bryner sees this on linux, so marking all/all... in fact, i *think* i also recently saw this on linux when i did a save from the context menu [would need to double-check with a more recent build]...
Comment 10•24 years ago
|
||
Happens on Win32 build 2001041704.
Comment 11•24 years ago
|
||
tentatively nominating... again, if this is really a dup, let us know. thx!
Keywords: nsbeta1
Comment 12•23 years ago
|
||
it's useless, and now it doesn't even work. remove the time elapsed textfield
altogether!
Comment 14•23 years ago
|
||
renominate for catfood --the user shouldn't have to see NaN:NaN in the download
progress dialog, ever, imho.
Keywords: nsCatFood- → nsCatFood
Comment 15•23 years ago
|
||
*** Bug 78877 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood → nsCatFood-
Reporter | ||
Comment 16•23 years ago
|
||
In
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/resources/downloadProgress.js#328:
function onCompletion( status ) {
// Note that we're done (and can ignore subsequent progress notifications).
completed = true;
// Indicate completion in status area.
var msg = getString( "completeMsg" );
msg = replaceInsert( msg, 1, formatSeconds( elapsed/1000 ) );
If *elapsed* is not initialized, probably the "NaN" is the output. *elapsed*
gets initialized with 0 in
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/resources/downloadProgress.js#182:
function onProgress( bytes, max ) {
// Check for first time.
if ( !started ) {
// Initialize download start time.
started = true;
startTime = ( new Date() ).getTime();
}
// Get current time.
var now = ( new Date() ).getTime();
// If interval hasn't elapsed, ignore it.
if ( now - lastUpdate < interval
&&
max != "-1"
&&
eval(bytes) < eval(max) ) {
return;
}
// Update this time.
lastUpdate = now;
// Update download rate.
elapsed = now - startTime;
If on Progress is not called due to a real fast download, *elapsed* never gets
initialized. We should initialize it with the definition as in
http://lxr.mozilla.org/seamonkey/source/xpfe/components/ucth/resources/helperAppDldProgress.js#38
that works the same way:
var elapsed = 0;
So line
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/resources/downloadProgress.js#149
should be changed.
(Sorry for the lengthy description, I still have to get aquainted with diffs.)
Reporter | ||
Comment 17•23 years ago
|
||
Nominating for 0.9.2 (assuming that my comments help in creating a fix).
Keywords: mozilla0.9.2
Reporter | ||
Updated•23 years ago
|
Comment 18•23 years ago
|
||
Still happening with version 0.9.3 on Mac OS 9.1. Quite disconcerting.
Reporter | ||
Comment 19•23 years ago
|
||
Is there any way I can keep the download window from closing after the download
has finished? It closes so fast that I cannot see if this bug is still there.
Comment 20•23 years ago
|
||
*** Bug 95359 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
oliver: if you're saving via the main menu or context menu [or accel+S], there
alas isn't a way [afaik] to make the progress dialog persist. however, if you're
downloading via the helper app dialog, the progress dialog resulting from there
does have a checkbox you can select to keep the dialog up. what i do [if the
checkbox had been deselected] is go an download a large-ish file, so that the
progress dialog stays up for more than a second, then quickly select that
checkbox. :)
Reporter | ||
Updated•23 years ago
|
Reporter | ||
Comment 22•23 years ago
|
||
Reporter | ||
Comment 23•23 years ago
|
||
Attached fix. Whom should I cc: for comments/r/sr?
As this is my first patch, I'd greatly appreciate help and comments on how to
make good (or better) patches.
Comment 24•23 years ago
|
||
http://www.mozilla.org/hacking/code-review-faq.html
http://mozilla.org/hacking/reviewers.html
should give you the necessary information.
look at lxr who has changed the file recently, and ask them via mail.
Assignee | ||
Comment 25•23 years ago
|
||
Your patch is great; thanks. I'll review it, find a super-reviewer, and get it
checked in.
Status: NEW → ASSIGNED
Assignee | ||
Comment 26•23 years ago
|
||
Comment on attachment 49534 [details] [diff] [review]
patch v1
r=law
Attachment #49534 -
Flags: review+
Comment 27•23 years ago
|
||
spam: over to File Handling.
Component: XP Apps: GUI Features → File Handling
Comment 28•23 years ago
|
||
Comment on attachment 49534 [details] [diff] [review]
patch v1
sr=blake, but please don't add that comment, I don't see the usefulness of it. (It'd be nice if all those global variables were prefixed with g, as has become something of a convention in js files; that would be enough of an indicator).
Attachment #49534 -
Flags: superreview+
Assignee | ||
Comment 29•23 years ago
|
||
fixed
Comment 30•23 years ago
|
||
Is there a reason for keeping this ASSIGNED rather than FIXED?
Assignee | ||
Comment 31•23 years ago
|
||
Yes. I forgot to push that "Resolve bug, changing resolution to FIXED" radio
button. But I think I got it this time :-). Thanks.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 32•23 years ago
|
||
*** Bug 104653 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
have not seen this recently, so vrfy'ing fixed.
Status: RESOLVED → VERIFIED
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•