By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,027 Members | 1,111 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,027 IT Pros & Developers. It's quick & easy.

setTimeout() & ECMA

P: n/a
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

Mar 11 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a
On 11 Mar 2006 12:38:13 -0800, "Andre" <an***********@gmail.com>
wrote:
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.
Mar 11 '06 #2

P: n/a
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 11 '06 #3

P: n/a
>> 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.


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/
Mar 11 '06 #4

P: n/a
Douglas Crockford said the following on 3/11/2006 5:56 PM:
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.


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 12 '06 #5

P: n/a
On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
<Hi************@aol.com> wrote:
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/20************...3c4-bis.w3.org >

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

Jim.
Mar 12 '06 #6

P: n/a
Andre wrote:
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
Mar 12 '06 #7

P: n/a
Jim Ley said the following on 3/11/2006 7:17 PM:
On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
<Hi************@aol.com> wrote:
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.


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/20************...3c4-bis.w3.org >

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


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

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 12 '06 #8

P: n/a
JRS: In article <11*********************@j33g2000cwa.googlegroups. com>,
dated Sat, 11 Mar 2006 12:38:13 remote, seen in
news:comp.lang.javascript, Andre <an***********@gmail.com> posted :
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.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Mar 12 '06 #9

P: n/a
>>>> 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 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?


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/
Mar 13 '06 #10

P: n/a
Douglas Crockford said the following on 3/12/2006 8:43 PM:
> 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 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?


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 13 '06 #11

P: n/a
VK

Randy Webb wrote:
Jim Ley said the following on 3/11/2006 7:17 PM:
On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
<Hi************@aol.com> wrote:
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.


Agreed.


Disagreed.
See
<http://groups.google.com/group/comp.lang.javascript/browse_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.

Mar 13 '06 #12

P: n/a
VK said the following on 3/13/2006 3:43 AM:
Randy Webb wrote:
Jim Ley said the following on 3/11/2006 7:17 PM:
On Sat, 11 Mar 2006 18:55:20 -0500, Randy Webb
<Hi************@aol.com> wrote:

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.

Agreed.


Disagreed.
See
<http://groups.google.com/group/comp.lang.javascript/browse_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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 13 '06 #13

P: n/a
On Mon, 13 Mar 2006 01:43:50 GMT, Douglas Crockford
<no****@sbcglobal.net> wrote:
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.
Mar 13 '06 #14

P: n/a
Jim Ley said the following on 3/13/2006 5:31 AM:
On Mon, 13 Mar 2006 01:43:50 GMT, Douglas Crockford
<no****@sbcglobal.net> wrote:
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

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 13 '06 #15

P: n/a
On Mon, 13 Mar 2006 18:40:24 -0500, Randy Webb
<Hi************@aol.com> wrote:
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


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.
Mar 14 '06 #16

P: n/a
Jim Ley said the following on 3/13/2006 7:50 PM:
On Mon, 13 Mar 2006 18:40:24 -0500, Randy Webb
<Hi************@aol.com> wrote:
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


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?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 14 '06 #17

P: n/a
VK

Randy Webb wrote:
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.

Mar 14 '06 #18

P: n/a
On 14 Mar 2006 03:54:07 -0800, "VK" <sc**********@yahoo.com> wrote:
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.
Mar 14 '06 #19

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
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.lang.javascript/browse_frm/thread/31734a3b21535ff5/eb99e9ae13739a95>

Mar 14 '06 #20

P: n/a
VK wrote:
Thomas 'PointedEars' Lahn wrote:
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.


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

<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/31734a3b21535ff5/eb99e9ae13739a95>

Unsurprisingly, your code is unnecessarily complicated and proprietary.

However, I find it very disturbing that referring to a JavaScript string
value that contains C++ source code with "javascript:..." as `src' of an
`img' element actually works in Gecko. Hopefully this is a security leak
that is fixed soon. Unless I miss something important here.
PointedEars
Mar 14 '06 #21

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
However, I find it very disturbing that referring to a JavaScript string
value that contains C++ source code with "javascript:..." as `src' of an
`img' element actually works in Gecko. Hopefully this is a security leak
that is fixed soon. Unless I miss something important here.


You do.
While the content of the string looks like C-code (or C++), it is also
exactly the format of XBM images (apparently someone thought it would
make it easier to include images in C programs if they were C code
aready).

The "Javscript:" pseudo protocol is interpreted by the browser to mean
"evaluate the javascript expression and use the resulting string as
the result of the link". In this place, Gecko tries to detect the
format of the resulting image, and correctly detects it as an XBM
image.

I would prefer a data: URL instead, which would also be much shorter
(and I would avoid using the proprietary feature of continuting a
string literal over several lines by ending lines with backslashes).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 15 '06 #22

P: n/a
VK

Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
However, I find it very disturbing that referring to a JavaScript string
value that contains C++ source code with "javascript:..." as `src' of an
`img' element actually works in Gecko. Hopefully this is a security leak
that is fixed soon. Unless I miss something important here.


You do.
While the content of the string looks like C-code (or C++), it is also
exactly the format of XBM images (apparently someone thought it would
make it easier to include images in C programs if they were C code
aready).

The "Javscript:" pseudo protocol is interpreted by the browser to mean
"evaluate the javascript expression and use the resulting string as
the result of the link". In this place, Gecko tries to detect the
format of the resulting image, and correctly detects it as an XBM
image.

I would prefer a data: URL instead, which would also be much shorter
(and I would avoid using the proprietary feature of continuting a
string literal over several lines by ending lines with backslashes).


Break! :-D

As I said in the original "Santa Time" thread, one is welcome to use
any graphics instead or even simple colored div squares - it has
absolutely no effect on timing issues I wanted to demonstrate.

I just wanted (besides the original task) to make dynamic XBM images to
work - and I wanted to conduct a kind of survey on their support among
browsers and platforms. IE had some vulnerabilty to them, so since XP
SP2 this method doesn't work anymore. This alas renders the whole
method rather useless for a wide run.

url(data) from CSS2 is more convenient, but currently fully supported
by Opera only AFAIK. Also IE had some vulnerability to this too, so
this option is currently locked - and even if unlocked it will be under
the IE's GET length limit (20?? - you look) so one can render this way
only really tiny images.

Continuting a string literal over several lines by ending lines with
backslashes is not a proprietary feature of a particular browser. It is
an exploit of the core mechanics of how script source is being
delivered from the server and how script tokenizer works. No one
browser with script support - starting with the oldest ones - has a
chance to follow the relevant ECMA spec in this case. For this the
tokenizer algorythm has to be re-written - but it will break too many
of currently existing and perfectly valid scripts. As such string is
being treated as one literal instead of multiple concatenations, one
gets a tremendous productivity raise. Another question that if one
needs a huge string literal inside script then there must be something
wrong with the concept. :-)

Mar 15 '06 #23

P: n/a
JRS: In article <11**********************@i39g2000cwa.googlegroups .com>
, dated Wed, 15 Mar 2006 00:51:41 remote, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :

Continuting a string literal over several lines by ending lines with
backslashes is not a proprietary feature of a particular browser. It is
an exploit of the core mechanics of how script source is being
delivered from the server and how script tokenizer works.

I find that it works, for me, on material entered in a TextArea and
displayed either through eval or document.write. No server is involved
in this case; the feature is evidently present in the browser. Tested
in <URL:http://www.merlyn.demon.co.uk/js-quick.htm>.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Mar 15 '06 #24

P: n/a
"VK" <sc**********@yahoo.com> writes:
Continuting a string literal over several lines by ending lines with
backslashes is not a proprietary feature of a particular browser.
No, it is a proprietary (meaning non-standardized) feature of several
browsers. It's not allowed by the ECMAScript standard though.
A string literal may not contain a line terminator.
(on the other hand, it may not contain the character sequence "\/",
which is recommended by the HTML standard for avoiding the sequence
"</" in javascript code, and we happily do that :)
It is an exploit of the core mechanics of how script source is being
delivered from the server and how script tokenizer works.
The script tokenizer is definitly responsible, but the behavior is
not accidental. It has been deliberatly coded into the tokenizer.
It's not a bad idea either, it's just not (de jura) standard.
No one browser with script support - starting with the oldest ones -
has a chance to follow the relevant ECMA spec in this case. For this
the tokenizer algorythm has to be re-written
Well, then do it. It's not like it's hard to change the rules.
Unless, ofcourse, that the feature is deliberate.
- but it will break too many of currently existing and perfectly
valid scripts.
Exactly (apart from the "perfectly valid" part). It's a non-standard
feature. People have used it. Ergo, it won't go away.
As such string is being treated as one literal instead of multiple
concatenations, one gets a tremendous productivity raise.
Hardly something a reasonable implementation wouldn't be able
to optimize. In Java, concatenation of compile time constants
must be performed at compile time.
Another question that if one needs a huge string literal inside
script then there must be something wrong with the concept. :-)


Large string constants would be a perfect candidate for storing
externally in languages that have a way of loading them at runtime.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 16 '06 #25

P: n/a
Lasse Reichstein Nielsen <lr*@hotpop.com> writes:
In Java, concatenation of compile time constants
must be performed at compile time.


I take that back. The Java Language Specification doesn't require
this, but it does appear to allow it, and it is necessary to do
concatenation at compile time when it appears in the declaration of a
constant.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 16 '06 #26

P: n/a
On 16/03/2006 00:43, Lasse Reichstein Nielsen wrote:

[snip]
A string literal may not contain a line terminator.
(on the other hand, it may not contain the character sequence "\/",


It certainly may.

StringLiteral ::
-> " DoubleStringCharacters[opt] "
' SingleStringCharacters[opt] '

DoubleStringCharacters ::
-> DoubleStringCharacter DoubleStringCharacters[opt]

DoubleStringCharacter ::
SourceCharacter but not double-quote " or backslash \ or
LineTerminator
-> \ EscapeSequence

EscapeSequence ::
-> CharacterEscapeSequence
0 [lookahead ∉ DecimalDigit]
HexEscapeSequence
UnicodeEscapeSequence

CharacterEscapeSequence ::
SingleEscapeCharacter
-> NonEscapeCharacter

NonEscapeCharacter ::
-> SourceCharacter but not EscapeCharacter or LineTerminator

A forward slash is neither an EscapeCharacter nor a LineTerminator,
therefore it qualifies as a SourceCharacter and the StringLiteral
production is met.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Mar 16 '06 #27

P: n/a
Thomas 'PointedEars' Lahn wrote:
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.


String literals are pointers to character data, C++ strings are not.
They might be under the hood, or they might not.

--
Ian Collins.
Mar 16 '06 #28

P: n/a
Michael Winter <m.******@blueyonder.co.uk> writes:
On 16/03/2006 00:43, Lasse Reichstein Nielsen wrote:

[snip]
A string literal may not contain a line terminator.
(on the other hand, it may not contain the character sequence "\/",


It certainly may.


True. Thanks.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 16 '06 #29

This discussion thread is closed

Replies have been disabled for this discussion.