a setTimeout() with a large interval is prematurely called when another call to setTimeout() is made




DOM: Core & HTML
13 years ago
11 years ago


(Reporter: David Fumberger, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)





13 years ago
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 
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

	setTimeout("alert('I should be called in 50060000 seconds')", "50060000");
<BUTTON onclick="setTimeout('return true;', 1);">Click me to raise the previous setTimeout</BUTTON>
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

Comment 1

13 years ago
Dup of bug 291386?

Comment 2

13 years ago
*** Bug 318463 has been marked as a duplicate of this bug. ***

Comment 3

13 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

13 years ago
Releated bug 318419 has a severity of "Major".  Can we up the severity of this?  

Comment 5

13 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

13 years ago
*** Bug 316933 has been marked as a duplicate of this bug. ***

Comment 7

13 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.


13 years ago
Version: 1.8 Branch → Trunk
Dup (forward-dup) of bug 318419?


Comment 9

12 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);

Comment 10

12 years ago
Forgot to mention my User-Agent:

  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/

Comment 11

12 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.
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 (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 ***
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Comment 13

12 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

12 years ago
A error or warning being logged to the Javascript console would be handy here, when the max is passed.
(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

12 years ago
*** Bug 321666 has been marked as a duplicate of this bug. ***


11 years ago
Duplicate of this bug: 310847
You need to log in before you can comment on or make changes to this bug.