10637 - setTimeout(functionReference, delay, arg) causes two arguments

Status: RESOLVED DUPLICATE of bug 394769

(Core Graveyard :: Viewer App, defect, P3)

Description

[martin.honnen]

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.

Comment 1

[martin.honnen]

Attachment: bug demo

Comment 2

[rickg]

Vidur -- one for you I think.

Comment 3

[vidur (gone)]

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?

Comment 4

[vidur (gone)]

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.

Comment 5

[vidur (gone)]

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.

Comment 6

[Scott Furman]

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

Comment 7

[martin.honnen]

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.

Comment 8

[vidur (gone)]

Fair enough - this should be documented, but I'd prefer to maintain 4.x
compatibility rather than change this. Marking the bug WONTFIX.

Comment 9

[Prashant Desale]

Verified.

Comment 10

[Jesse Ruderman]

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

Comment 11

[Jesse Ruderman]

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

Comment 13

[laurent vilday]

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.

Comment 14

[BAM]

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)