94091 - changing the system clock changes download-in-progress window's clocks

Status: VERIFIED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Aaron Nielsen]

(I didn't know where exactly to file this, so I just selected Browser (General)
from the Component list.)
Using Win98SE and Mozilla 0.9.2, changing the system clock while a download is
in progress wreaks almighty havoc with the clocks maintained by the download
window.  When the system time is set forward by one day, the elapsed time
increases by 24 hours, and the data rate and time remaining are changed
"accordingly".

To reproduce:
------------

(1) Using Mozilla, start downloading something that will take a few minutes,
such as a new Mozilla build. :)  Keep this download window handy.

(2) In the Windows tray, right-click the clock and select Adjust Date/Time.  Set
the calendar forward by one day, leaving the clock to tick normally otherwise.
(3) Return to the download window, noting the warped values shown by the timers
therein.

Results:
-------

The Elapsed Time clock in the download window as increased by 24 hours,
adjusting the Remaining Time clock and the Data Rate (x.x kB/s) value.  Of
course, this figure is now wrong.

* * *

What do you do about a phenomenon like this?  How would you know if the system
clock has changed?  Can the download window manage its own clocks independently
from the system clock, since it only needs one-second precision?
An interesting one, but I am yet to verify this with 0.9.3.

Comment 1

[timeless]

do we have to get this right?

Comment 2

[Aaron Nielsen]

As I said, I don't really know what *I* would do about it.  I'm sure there's an
easy (read, understandable) fix, but how often are you going to change the
system clock?  And what are the chances that you'll have a download window up
while you're doing it?
Do you have a negative priority feature anywhere?  This one should go *way* down
on the list of things to do - anything else to do is probably far more
important.  It's just an interesting phenomenon.

Comment 3

[timeless]

P5 Least important. I agree w/ reporter and think that's reasonable. I suppose 
we'd have to ask JSDOM or JSENG if this is possible... Confirming 'bug'...

Comment 4

[Phil Schwartau]

cc'ing Kenton, Roger, and Patrick for any JS Engine opinion on this - 

Comment 5

[Blake Ross]

Thanks for not changing priority on my bugs.

Comment 6

[sairuh (rarely reading bugmail)]

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. :)

Comment 7

[Blake Ross]

-->law

Comment 8

[Bill Law]

This is funny.  We have no way of finding out what the time *really* is.  Nor do
you.  Ask Einstein.

Comment 9

[sairuh (rarely reading bugmail)]

mass verification of Invalid bugs: to find all bugspam pertaining to this,
set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. where relevant, do check that it's actually still a problem with ***recent
trunk builds*** on the all appropriate platform[s]

b. provide clear, compelling reasons why this bug should be considered a valid one.