Closed
Bug 316491
Opened 19 years ago
Closed 18 years ago
a setTimeout() with a large interval is prematurely called when another call to setTimeout() is made
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 318419
People
(Reporter: djfumberger, Unassigned)
References
()
Details
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.
Updated•19 years ago
|
Assignee: nobody → general
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Comment 1•19 years ago
|
||
Dup of bug 291386?
Comment 2•19 years ago
|
||
*** Bug 318463 has been marked as a duplicate of this bug. ***
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
Releated bug 318419 has a severity of "Major". Can we up the severity of this?
Comment 5•19 years ago
|
||
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...
Comment 6•19 years ago
|
||
*** Bug 316933 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
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.
Updated•19 years ago
|
Version: 1.8 Branch → Trunk
Comment 8•18 years ago
|
||
Dup (forward-dup) of bug 318419? /be
Comment 9•18 years ago
|
||
I seem to be seeing this issue to. It doesn't happen all the time, but when it starts happening it continues. My script is as follows: <script language="JavaScript" type="text/javascript"> treeNode = ''; currentPageName = '/Inventory.do'; function goLogin(){ window.location = '/Login.do?timeout=true'; } function onBodyLoad(){ setTimeout('requestAlarmsSummary()', 5000); // loginCookieSet:true var timeoutValue = 15; if (timeoutValue > 0){ setTimeout('goLogin()', timeoutValue * 50000); } } </script>
Comment 10•18 years ago
|
||
Forgot to mention my User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Comment 11•18 years ago
|
||
A few more observations: - reloading the page makes no difference - turning off Javascript prevents the issue (of course) - turning on Javascript again causes the symptoms to resume after the page is reloaded. - restarting Firefox clears the issue In my situation we have a login page that directs us to the site content. Each site content page has a timeout applied to it, so that after x time of 'inactivity' an auto-logout will be performed, sending the user back to the main screen. The problem is that when the issue starts, the users can login, but when getting to the content they keep getting sent back to the login page. I do have tabs open. I am not sure, but I believe Firefox has been open a while and I have been working on the site a while, before the symptoms show. I can't share the site with you, since it is being used for an internal product.
Comment 12•18 years ago
|
||
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 1.5.0.2 (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
Closed: 18 years ago
Resolution: --- → DUPLICATE
Comment 13•18 years ago
|
||
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.
Comment 14•18 years ago
|
||
A error or warning being logged to the Javascript console would be handy here, when the max is passed.
Comment 15•18 years ago
|
||
(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.
Comment 16•18 years ago
|
||
*** 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.
Description
•