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

Status: RESOLVED DUPLICATE of bug 10637

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

Description

[Shawn Grunberger]

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.

Comment 1

[Peter Van der Beken [:peterv]]

IIRC there's always an argument added to the function call that contains the
'timeout lateness'. Why is this a problem?

Comment 2

[Johnny Stenback (:jst)]

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?

Comment 3

[Shawn Grunberger]

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.

Comment 4

[Bob Clary [:bc] (inactive)]

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

Comment 5

[Mike Shaver (:shaver emeritus)]

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.

Comment 6

[Shawn Grunberger]

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

Comment 7

[Brendan Eich [:brendan]]

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

Comment 8

[Jesse Ruderman]

*** Bug 304771 has been marked as a duplicate of this bug. ***

Comment 9

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 10637 ***