Calling setTimeout or setInterbal with a function reference and a delay causes the called function to have one additional argument to the passed ones e.g. function checkSetTimeout (arg) { debug.document.write('arguments.length: ' + arguments.length + '<BR>'); for (var i = 0; i < arguments.length; i++) debug.document.write('arguments[' + i + ']: ' + arguments[i] + '<BR>'); if (confirm('again')) setTimeout (checkSetTimeout, 1000, arg); } setTimeout (checkSetTimeout, 1000, 'Kibology'); shows arguments.length as 2 That is actually irking people with NN4 but occurs with mozilla as well. Note that the example needs the viewer as I used confirm to demonstrate the bug. I file it on the viewer as I am not sure where js issues not relating to core ecma belong to.
Created attachment 1018 [details] bug demo
Vidur -- one for you I think.
As you mention, this happens with Nav 4.x as well. The implementors of setTimeout added the extra argument - it is the lateness of the timeout in milliseconds. Is this truly a problem for JavaScript users?
Turns out that setTimeout passing in a function argument got busted with Norris' recent checkin. He passes a JSObject* into nsIScriptContext::CallFunction() instead oa JSFunction*. Since the nsIScriptContext interface tries to be language-neutral, void* are passed around. Hence, the problem wasn't caught by the compiler.
The timeout problem described in my previous comment has been fixed for a while. Again, I'd like to understand why that extra argument is a problem. If there's a compelling reason, I can remove it. Cc:ing Scott Furman in case he'd like to take part in this discussion.
I doubt that this extra argument is used by anyone, since we never documented it. It was very useful to *us* at Netscape in performance testing of animation using intervals, since a script could detect when the CPU became saturated, i.e. the timeout lateness was increasing monotonically with each timeout. Given that it's backward-compatible with NN4, I don't see a reason to change it, though we might want to finally document it. There would have to be a pretty compelling reason to
I would prefer to have those arguments in a function I passed in and not one more, it is particularly troublesome for code looping trough arguments expecting to process the passed arguments, and the bug report actually resulted from a newsgroup post where someone wondered why the additional argument is around so if you decide to keep it at least document it.
Fair enough - this should be documented, but I'd prefer to maintain 4.x compatibility rather than change this. Marking the bug WONTFIX.
Verified.
*** Bug 263945 has been marked as a duplicate of this bug. ***
*** Bug 329160 has been marked as a duplicate of this bug. ***
*** Bug 408378 has been marked as a duplicate of this bug. ***
Come on, WONTFIX because of netscape 4.X backward compatibility ? You can't be serious, are you ? This is exactly the way Microsoft started to mess up IE 10 years ago. Is the Mozilla goal is to looks like Microsoft in 10 years from now ? Come on, fix the bug and get rid of any NS4 backward compatibility, this has to be a joke.
Netscape is no longer a supported browser, OFFICIALLY! Can you please fix this... (since I have to support all versions of Firefox 1.5+, it won't matter to me today, but I think that backwards compatibility with NN4 should no longer be used as a reason for WONTFIX bugs)
*** This bug has been marked as a duplicate of bug 394769 ***
or
