Closed Bug 263945 Opened 20 years ago Closed 18 years ago

setTimeout and setInterval pass bogus parameter when called with a function reference

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 10637

People

(Reporter: shawng, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When the first parameter to setTimeout or setInterval is a function reference,
that function is called with single, random-appearing integer parameter. When
passing a string to setTimeout/setInterval, this does not occur.

Reproducible: Always
Steps to Reproduce:
1. Using Firefox 0.9 or 1.0PR, navigate a browser window to about:blank.
2. Enter the following in the location bar and hit Enter:

 javascript:setTimeout( function() { alert( arguments[0] ); }, 1000 ); void 0;

3. After one second, an alert will appear containing a integer. 
4. Repeat steps 1-3. You will receive a series of random-appearing integers.
5. Repeat again, replacing setTimeout with setInterval. You'll need to close the
browser window to get the alerts to stop.

Actual Results:  
I received a series of random-appearing integers.

Expected Results:  
The alert should be empty (or, potentially, say "undefined") each time. The
function called via setTimeout or setInterval should not have any parameters
passed to it in this case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
IIRC there's always an argument added to the function call that contains the
'timeout lateness'. Why is this a problem?
Yes, this is as designed, and this is how setTimeout() and setInterval() have
behaved in Netscape since the beginning of their existance, AFAIK. How is this a
problem?
In general, I'm against secret parameters passed automatically into user 
functions. Especially if the parameter is of doubtful usefulness. However, if 
this is established behavior, then I'm willing to concede. 

I wonder also if this parameter is working as expected. Although it's often a 
value like 1, 4, or 7, I fairly frequently see values like 76791831. How is 
this useful?

Our scenario, simplified a bit, was a function that took a variable number of 
parameters. The function examined arguments.length to determine its behavior. 
When passed into setTimeout(), it expected to be called with zero parameters, 
but was not.

Yes, I could pass in a string to setTimeout() to suppress the secret 
parameter, but in this case it's an anonymous function that isn't easily 
reached from the global namespace.

Preferrably, this extra parameter should be documented. I believe that might 
fall under bug 243630.

Thanks for your attention.
Ok, I guess I shouldn't have confirmed this, but I did check the JS 1.5
reference on DevEdge (at least Google's cache of it) and didn't see
documentation on the parameter. -> INVALID
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
This is indeed an underdocumented feature of the classic DOM0, which we might
someday remedy under the aegis of devmo.  In the meantime, you could interpose a
wrapper function which explicitly called your user function with zero arguments,
and register that with setTimeout.

Thanks for the thoughtful comment; the large-number case might indeed be a bug,
as there do still lurk some timer gremlins.
> you could interpose a wrapper function which explicitly called 
> your user function with zero arguments, and register that with setTimeout

Yes, I actually ended up overriding setTimeout/setInterval so that's done 
automatically.

Thanks again.
Re: comment 2, IIRC fur actually added the lateness secret actual parameter in
Netscape 3 (or was it 4?).  My original implementation of setTimeout in Netscape
2 lacked this secret argument (setInterval came later).

/be
*** Bug 304771 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

*** This bug has been marked as a duplicate of 10637 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.