setTimeout() & ECMA

A

Andre

Hi,

Does anyone know whether the ECMA, or an other standard document,
specifies a maximum for the value that can be pass to the setTimeOut()
function in Javascript?

Andre
 
J

Jim Ley

Does anyone know whether the ECMA, or an other standard document,
specifies a maximum for the value that can be pass to the setTimeOut()
function in Javascript?

setTimeout is not standardised anywhere.

Jim.
 
R

Randy Webb

Andre said the following on 3/11/2006 3:38 PM:
Hi,

Does anyone know whether the ECMA, or an other standard document,
specifies a maximum for the value that can be pass to the setTimeOut()
function in Javascript?

It would surprise me if there was one as it's irrelevant to the language
itself. But, if it does exist, then it's irrelevant anyway because I can
write a timeout to last as long as I want no matter what any spec may say.
 
D

Douglas Crockford

Does anyone know whether the ECMA, or an other standard document,
It would surprise me if there was one as it's irrelevant to the language
itself. But, if it does exist, then it's irrelevant anyway because I can
write a timeout to last as long as I want no matter what any spec may say.

It may surprise you that setTimeout is not covered by an ECMA standard, nor by a
W3C standard. There are some holes in the web standards. This is one of them.
I'm looking to the WHAT Working Group to fix this. See
http://www.whatwg.org/specs/web-apps/current-work/

There doesn't seem to be a problem in setting the timeout value to something
that is vastly greater than the MTBF of the browser. All that means is that the
timeout may never fire.

http://javascript.crockford.com/
 
R

Randy Webb

Douglas Crockford said the following on 3/11/2006 5:56 PM:
It may surprise you that setTimeout is not covered by an ECMA standard,
nor by a W3C standard.

It does but it doesn't.
There are some holes in the web standards. This is one of them. I'm
looking to the WHAT Working Group to fix this. See
http://www.whatwg.org/specs/web-apps/current-work/


Is there some underlying problem with setTimeout that it needs to be
standardized for any reason other than so it is standardized?

There doesn't seem to be a problem in setting the timeout value to
something that is vastly greater than the MTBF of the browser. All that
means is that the timeout may never fire.

True. But even if there were a limit to a single call to setTimeout you
can exceed that limit by using multiple or recursive setTimeouts to get
the desired result. So any attempt to set a limit on the timer of
setTimeout would lead to more problems than it ever tried to solve and
would lead to code that looked something like this:

var timer1 = 0;
var loops = 30;

function SetTimeOut(){
if (timer1 == loops)
{
realFunctionYouWantToCall();
}
else{
timer1++;
window.setTimeout(SetTimeOut,maxValue);
}
}
window.setTimeout(SetTimeOut,maxValue);

Where maxValue would be the maximum value you could pass to setTimeout.
 
J

Jim Ley

Is there some underlying problem with setTimeout that it needs to be
standardized for any reason other than so it is standardized?

None at all, these de facto standards don't need to be standardised,
in fact standardising them can be very difficult. What is useful is
documenting what UAs do in a single place.

The WHAT WG Individual here is doing a valuable thing, unfortunately
writing it up as a spec is less helpful.

In any case, the work on the window object is also being documented by
W3 WEB API group <URL: http://www.w3.org/2006/webapi/ > including
setTimeout - You can even join in the discussion, e.g. <URL:
http://www.w3.org/mid/[email protected] >

(and is likely to leave the Web Apps in the WHAT...)

Jim.
 
T

Thomas 'PointedEars' Lahn

Andre said:
Does anyone know whether the ECMA, or an other standard document,
specifies a maximum for the value that can be pass to the setTimeOut()
function in Javascript?

There is no setTimeOut() function, and there is no Javascript.
That was easy :)

Seriously, the language we are talking about in this case is either
(Netscape) JavaScript, or (Microsoft) JScript, or an implementation
of one or both of them. With the exception of JavaScript 1.0, both
languages are indeed conforming ECMAScript implementations.

But as Jim already said, setTimeout(), as it is spelled properly,
is not defined by any specification as yet. It is a method of the
host object that can be referred to by `window' (and often, if not
always, a method of the Global Object in HTML UAs), which was never
really a part of any programming language, instead it is a feature
of the AOM/DOM of an HTML user agent. (Although it is included in
the JavaScript References from versions 1.0 to 1.3, thereby referring
to the Netscape Navigator AOM/DOM.)

Probably you mean the value of the second argument of that method,
specifying the timeout length in milliseconds. So far there is no
reference material that says anything about a maximum value for it
explicitly:

JavaScript 1.3 Reference
<URL:http://research.nihonsoft.org/javascript/ClientReferenceJS13/window.html#1203758>

Gecko DOM Reference
<URL:http://developer.mozilla.org/en/docs/DOM:window.setTimeout>

MSDN Library: HTML and DHTML Reference
<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/settimeout.asp>

Opera DOM
<URL:http://www.opera.com/docs/specs/opera6/js/index.dml>

KHTML (Konqueror, Safari)
<http://developer.kde.org/documentation/library/3.1-api/khtml/html/classKJS_1_1ScheduledAction.html>
....
<http://developer.kde.org/documentation/library/3.4-api/khtml/html/classKJS_1_1ScheduledAction.html>

But for some UAs, you can read the Source, Luke:

<URL:http://lxr.mozilla.org/mozilla1.8.0/source/dom/src/base/nsGlobalWindow.cpp#5971>

The lines

| #define DOM_MAX_TIMEOUT_VALUE PR_BIT(8 * sizeof(PRIntervalTime) - 1)

and

,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prtypes.h#240>
| #define PR_BIT(n) ((PRUint32)1 << (n))

,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prinrval.h#61>
| typedef PRUint32 PRIntervalTime;

,-<URL:http://lxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/include/prtypes.h#330>
| typedef unsigned int PRUint32;

suggest (if I understand it correctly) that the maximum timeout length in a
Gecko-based UAs compiled for and running on a 32-bit machine is (following
the preprocessor steps)

PR_BIT(8 * sizeof(PRIntervalTime) - 1)
== ((unsigned int)1 << (8 * sizeof(PRUint32) - 1))
== ((unsigned int)1 << (8 * sizeof(unsigned int) - 1))
== ((unsigned int)1 << (8 * 4 - 1))
== ((unsigned int)1 << 31)
== 2147483648

milliseconds, which equals 24 standard days, 20 hours, 31 minutes, and
23.648 seconds. According to nsGlobalWindow.cpp, lines 6051 to 6055,
greater values will be normalized to that value.

What is most interesting is that this source code also makes it clear that
Gecko 1.8.0-based UAs (such as Firefox 1.5.0.1) will not handle timeouts or
intervals shorter than 10 milliseconds (nsGlobalWindow.cpp, lines 6044 to
6049, and 191 and 192). So if you provide a smaller value, the actual
timeout/interval length will be 10 milliseconds.

And for KHTML-based UAs:

<URL:http://developer.kde.org/documentation/library/3.4-api/khtml/html/kjs__window_8h-source.html#l00177>

Since the value must be parsed by an ECMAScript implementation, the general
theoretical maximum value is max(IEEE754_DOUBLE), 1.798E308, which equals
about 5.7E297 years. However, it is probable that other implementations
also use an Integer type here, which would restrict the maximum value for
window.setTimeout() to the maximum value an extended integer register can
hold on the particular platform, assuming the use of a generic data type
in the UA's source code, such as `unsigned int' in C++.

If you mean the length of the string that can be used as the first argument
instead, there is nothing in the reference material about that either.
String literals (and C++ strings, which are in fact pointers to character
data) can be of arbitrary length; it is just a matter of available memory.


HTH

PointedEars
 
R

Randy Webb

Jim Ley said the following on 3/11/2006 7:17 PM:
None at all, these de facto standards don't need to be standardised,
in fact standardising them can be very difficult. What is useful is
documenting what UAs do in a single place.
Agreed.

The WHAT WG Individual here is doing a valuable thing, unfortunately
writing it up as a spec is less helpful.

Understood. As long as there is no limit on the time, as I showed, it is
easily circumvented making it moot to add it and only leads to
complicating code.
In any case, the work on the window object is also being documented by
W3 WEB API group <URL: http://www.w3.org/2006/webapi/ > including
setTimeout - You can even join in the discussion, e.g. <URL:
http://www.w3.org/mid/[email protected] >

(and is likely to leave the Web Apps in the WHAT...)

I might read up on it :) Looks to be interesting.
 
D

Dr John Stockton

JRS: In article <[email protected]>,
dated Sat, 11 Mar 2006 12:38:13 remote, seen in
news:comp.lang.javascript said:
Does anyone know whether the ECMA, or an other standard document,
specifies a maximum for the value that can be pass to the setTimeOut()
function in Javascript?

The value is a Number of milliseconds, and its limit is therefore the
maximum IEEE Double, a bit over 1.7E308, meaning about 5.3E297 years.

It's probable that the timeout operation will be implemented by the
operating system, and that the OS will impose a lower usable limit.
That's likely to be 2^N-1 ms, where N = 31 or 32. In Windows, 32,
allowing 49 days 17:02:47.295.

The MTBF of the browser should exceed 50 days; that of the OS might not.

Untested.
 
D

Douglas Crockford

Does anyone know whether the ECMA, or an other standard document,
Is there some underlying problem with setTimeout that it needs to be
standardized for any reason other than so it is standardized?

The original question was what does the standard say? When you look to the
standard to answer questions, and the standard does not exist, that could be
viewed as a problem.

The lack of a standard should also be a concern to people who are dedicated to
standards based development. There are some fierce web developers who refuse to
touch anything that is not strictly standards compliant. How can a browser be
fully standards compliant if there do not exist standards for it to conform to?

Defacto standards and proprietary standards are not sufficient, I think.

http://javascript.crockford.com/
 
R

Randy Webb

Douglas Crockford said the following on 3/12/2006 8:43 PM:
The original question was what does the standard say? When you look to
the standard to answer questions, and the standard does not exist, that
could be viewed as a problem.

Makes sense to me :)
The lack of a standard should also be a concern to people who are
dedicated to standards based development. There are some fierce web
developers who refuse to touch anything that is not strictly standards
compliant. How can a browser be fully standards compliant if there do
not exist standards for it to conform to?

Language extensions, which are allowed by the standards.

But, is there also a movement to standardize innerHTML? It would, to me,
fall into the same category.
Defacto standards and proprietary standards are not sufficient, I think.

That is why I was asking about the reason for standardizing it.
 
V

VK

Randy said:
Jim Ley said the following on 3/11/2006 7:17 PM:

Agreed.

Disagreed.
See
<http://groups.google.com/group/comp..._frm/thread/f127aa709e894c0c/0c0d836d49b2d779>

There is a huge discrepancy on handling timed execution calls (let's
spit over the shoulder and call it "threads" any further, keeping
"pseudo-" preffix in mind).

The way Firefox handles threads on modal dialog call (alert, confirm,
prompt) is not to say non-standard - as we don't have a written
standard - but highly innovative in the relation to the tradition.
Actually in order to accomplish that they also changed modal dialogs to
"half-modal" dialogs: dialogs from different threads allowed to popup
one behind other, so you can have N dialogs on the page at once -
though the page access is still locked until the last dialog is
dismissed. Thinking of any GIU I had to deal with I cannot come up with
any equivalent of that - though it is possibly of lack of OS
experience.

In any case it should be clearly documented - or changed to the
conventional way.
 
R

Randy Webb

VK said the following on 3/13/2006 3:43 AM:
Disagreed.
See
<http://groups.google.com/group/comp..._frm/thread/f127aa709e894c0c/0c0d836d49b2d779>

There is a huge discrepancy on handling timed execution calls (let's
spit over the shoulder and call it "threads" any further, keeping
"pseudo-" preffix in mind).

The way Firefox handles threads on modal dialog call (alert, confirm,
prompt) is not to say non-standard - as we don't have a written
standard - but highly innovative in the relation to the tradition.
Actually in order to accomplish that they also changed modal dialogs to
"half-modal" dialogs: dialogs from different threads allowed to popup
one behind other, so you can have N dialogs on the page at once -
though the page access is still locked until the last dialog is
dismissed. Thinking of any GIU I had to deal with I cannot come up with
any equivalent of that - though it is possibly of lack of OS
experience.

In any case it should be clearly documented - or changed to the
conventional way.

Let me quote it to you VK, ok?

<quote cite="Jim Ley">
What is useful is documenting what UAs do in a single place.
</quote>
<quote cite="Randy Webb">
Agreed
</quote>

Which is precisely what you just said.

If some organization came out tomorrow and attempted to standardize
setTimeout then I would definitely read it, but it wouldn't change my
thoughts about it. Standards are great, but not the end all of end alls.
I worry more about what browsers do than what some spec says they
*should* do. And a single place that documented how different browsers
handle setTimeout would be a lot more valuable to me than any standard
on it ever will be.
 
J

Jim Ley

Defacto standards and proprietary standards are not sufficient, I think.

And then you pointed to the WHAT-WG which is a proprietary standard
from a Google employee? [*] So I'm not sure what your point is.

Standards take an immense amount of work to produce - notes on what
people have done take much less, Hixie alone can do the later in a
couple of man years. Given things which are extremely interopable
there's little point in investing the cost of standardising them, when
there are a lot more important things to standardise.

If you have the time Douglas - join the Web API's Working Group, you
work for a member company - the more resources there are, the more
standards that can be produced.

Jim.

[*] With a debateable copyright notice pointing to other vendors.
 
R

Randy Webb

Jim Ley said the following on 3/13/2006 5:31 AM:
Defacto standards and proprietary standards are not sufficient, I think.

And then you pointed to the WHAT-WG which is a proprietary standard
from a Google employee? [*] So I'm not sure what your point is.

Standards take an immense amount of work to produce - notes on what
people have done take much less, Hixie alone can do the later in a
couple of man years.

I don't know if having a Jim Ley assigned nickname is a good thing or
not as I don't know of anyone else who has one :) Hmmm
 
J

Jim Ley

I don't know if having a Jim Ley assigned nickname is a good thing or
not as I don't know of anyone else who has one :) Hmmm

Hixie is not a Jim Ley assigned nickname, it's Ian's IRC nick, his
website address etc. I've even heard people use it to his face.

Jim.
 
R

Randy Webb

Jim Ley said the following on 3/13/2006 7:50 PM:
Hixie is not a Jim Ley assigned nickname, it's Ian's IRC nick, his
website address etc. I've even heard people use it to his face.

Can I go hide my face now?
 
V

VK

Randy said:
Let me quote it to you VK, ok?

oky-toky, you may try :)
<quote cite="Jim Ley">
What is useful is documenting what UAs do in a single place.
</quote>
<quote cite="Randy Webb">
Agreed
</quote>

Which is precisely what you just said.

I said that Firefox' setTimeout behavior is <q>highly innovative</q> -
and I should maybe say "overly innovative". And the options I asked was
either to provide a written commitment from Mozilla that this will be
forever until Firefox exists - or drop it for the standard behavior
before it's too late (unless it's already too late).
Here I'm taking "standard" not like something "described and sealed (by
W3C)" but in the most common primary sense: "something considered by an
authority or *by general consent* as a basis of comparison".
"by general consent" part is always conveniently ommited by W3C members
when they raise their eyes up and start talking about Standards. :)
<offtopic>
In the reality the "general consent" has much greater value than any
amout of signed papers. Until it's not clearly understood by W3C and Co
they will continue make nasty oopsies like say XHTML.
</offtopic>

setTimeout is not documented, nor alert, confirm or prompt. But there
is a public expectation of them and their behavior. I mean how many
chances do you give to a browser not having window.setTimeout or
window.alert ? I give Number.NEGATIVE_INFINITY - despite no one browser
is obligated by written standards to have it.

And I really don't like that for a decade now "window" is being bounced
from Pontius to Kijafa and back: ECMA doesn't take it because it's a
host object, W3C doesn't take because it's not a part of HTML. So such
vital and throughout implemented object is kind of out of any existing
schema.
If some organization came out tomorrow and attempted to standardize
setTimeout then I would definitely read it, but it wouldn't change my
thoughts about it. Standards are great, but not the end all of end alls.
I worry more about what browsers do than what some spec says they
*should* do. And a single place that documented how different browsers
handle setTimeout would be a lot more valuable to me than any standard
on it ever will be.

It really depends on how big a particular discrepancy is. If 20px plus
minus and so then it's semi OK - we have to live with this srap since
the beginning of time. :-(

If all browsers but one halt all threads on alert, but the one doesn't
- it's a Problem. Same if 90% of clients get real nodes count but in up
to 10% you have to expect phantom nodes counted so all build-in XML
methods are useless and you have to write wrappers atop of each - this
is a Problem.
 
J

Jim Ley

ECMA doesn't take it because it's a
host object, W3C doesn't take because it's not a part of HTML. So such
vital and throughout implemented object is kind of out of any existing
schema.

The W3 Web Api's working are writing up the standard as we speak,
Maciej has already posted one public editors draft, don't complain, go
join the mailing list, they are doing it all very much in public - (I
even managed to wonder into their face 2 face without any problems
other than the snow...)

http://www.w3.org/2006/webapi/

and the email list

http://lists.w3.org/Archives/Public/public-webapi/

and IRC channel

irc://irc.freenode.net:6667/#webapi

Jim.
 
V

VK

Thomas said:
What is most interesting is that this source code also makes it clear that
Gecko 1.8.0-based UAs (such as Firefox 1.5.0.1) will not handle timeouts or
intervals shorter than 10 milliseconds (nsGlobalWindow.cpp, lines 6044 to
6049, and 191 and 192). So if you provide a smaller value, the actual
timeout/interval length will be 10 milliseconds.

Excellent research. My Santas had to run many miles since December
before things started to go right :)

<http://groups.google.com/group/comp..._frm/thread/31734a3b21535ff5/eb99e9ae13739a95>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,175
Latest member
Vinay Kumar_ Nevatia
Top