User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 If I make a call to setTimeout with a large interval ie setTimeout("alert('I should be called in 50060000 seconds')", "50060000"); The next time setTimeout is called it will cause the code in the previous setTimeout to be executed. Smaller timeout periods don't suffer from the same issues (say 5006000) Reproducible: Always Steps to Reproduce: Here's the code to reproduce the problem <HTML> <HEAD></HEAD> <SCRIPT> setTimeout("alert('I should be called in 50060000 seconds')", "50060000"); </SCRIPT> </HEAD> <BODY> <BUTTON onclick="setTimeout('return true;', 1);">Click me to raise the previous setTimeout</BUTTON> </BODY> </HTML> Actual Results: When the button is clicked an alert shows 'I should be called in 50060000 seconds' Expected Results: The setTimeout initially set shouldn't be raised.
Assignee: nobody → general
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Dup of bug 291386?
*** Bug 318463 has been marked as a duplicate of this bug. ***
Absolutely reproducible on Firefox 1.5 for several users. Any call to setTimeout after a previous setTimeout has been called seems to kill the timer.
Releated bug 318419 has a severity of "Major". Can we up the severity of this?
bug 316933 is most likely a dup of this. I don't think this is a dom bug per se since I suspect it's a timer issue. I'll try to find people to cc on this...
*** Bug 316933 has been marked as a duplicate of this bug. ***
While the root cause of 316933 may well end up being resolved here, that bug dealt with end-user functionality. Setting the "mailnews.mark_message_read.delay.interval" to any value, big or small, results in unpredictable behavior. In my case, the feature is currently unusable as no matter what value I choose, unless it is very large, the message is marked as read in a couple of seconds. With large vlaues, the message is never marked.
Dup (forward-dup) of bug 318419? /be
Forgot to mention my User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060111 Firefox/184.108.40.206
Yes, this problem should've been fixed by the fix for bug 318419 since there we now cap large timeouts at the max timeout value that our timer code can handle. IOW no timeouts should ever fire right away any more if they're registered with a large timeout value. And btw, the actual timeout value needed to trigger this is different on different platforms (even different CPU speeds IIRC), so testers beware. This was fixed on the trunk, and in 220.127.116.11 (scheduled to be released shortly). If the problem remains in nightlies of either the trunk or the 1.8.0 branch, please undupe this. *** This bug has been marked as a duplicate of 318419 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Is the maximum valid timeout value documented somewhere and easy to find? I understand that you simply can't go higher than the maximum, but if you can't honor certain timeout values, and you're not going to produce an error for out of range values, then developers need to be made aware of or be able to easily find out what the expected behavior will be including the maximum timeout value.
(In reply to comment #13) > Is the maximum valid timeout value documented somewhere and easy to find? Not really, it's a platform dependent limit. From looking at the timer code and the nspr headers (http://lxr.mozilla.org/mozilla/source/nsprpub/pr/include/prinrval.h#57) the theoretical max value will be somewhere between 2^31/100000 and 2^31/1000 seconds (~6 - 600 hours), but the actual value depends on the system where the code is run. A message on the console isn't out of the question, feel free to file a bug on adding that.
*** Bug 321666 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.