setTimeout() & ECMA

[Thomas 'PointedEars' Lahn]

Excellent research.
Thanks.

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>

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

 

[Lasse Reichstein Nielsen]

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

 

[VK]

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 15 Mar 2006 00:51:41 remote, seen in

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

 

[Lasse Reichstein Nielsen]

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]

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

 

[Michael Winter]

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

 

[Lasse Reichstein Nielsen]

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