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)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 318419

People

(Reporter: djfumberger, Unassigned)

References

(
URL
)

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.
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.
Version: 1.8 Branch → Trunk
Dup (forward-dup) of bug 318419?

/be
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>
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
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 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 ***
URL: javascript:setTimeout("alert('first t...
Status: UNCONFIRMED → RESOLVED
Closed: 18 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.
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.
*** 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.