Weird innerHTML/appendChild IE crash
nick...@hotmail.com
reason why the following code crashes IE but if I add <br/> after ANY
<input> tags it doesn't?
******************************************************
HTML = "html before";
HTML += "\
<label for='m-bx'>X:</label><input type='text' id='m-bx'/>\
<label for='m-by'>Y:</label><input type='text' id='m-by'/>\
<label for='m-bw'>Width:</label><input type='text' id='m-bw'/>\
<label for='m-bh'>Height:</label><input type='text' id='m-bh'/>"
HTML += "html after";
bEditor = document.createElement("DIV");
bEditor.innerHTML = HTML;
dW.appendChild(bEditor);
******************************************************
Janwillem Borleffs
> Without knowing "html before" and "html after" can anyone fathom any
> reason why the following code crashes IE but if I add <br/> after ANY
> <input> tags it doesn't?
>
Doesn't crash IE on my system using document.body for dW. Where does dW
point to?
JW
nick...@hotmail.com
dW is just another DIV, and "html before" and "html after" each
represents 100+ lines of html code. Of course I can potentially
eliminate the code line by line and find out the culprit but I'm not
going to do that because it works now anyway and the problem is too
weird that I have absolutely no idea what to look for. I mean, can you
imagine ANY situation where:
"<label for='m-bh'>Height:</label><input type='text' id='m-bh'/><br/>"
works
and
"<label for='m-bh'>Height:</label><input type='text' id='m-bh'/>"
doesn't?
I mean, WTF??
Jim Ley
> I mean, can you
>imagine ANY situation where:
>
>"<label for='m-bh'>Height:</label><input type='text' id='m-bh'/><br/>"
>works
>and
>"<label for='m-bh'>Height:</label><input type='text' id='m-bh'/>"
>doesn't?
Neither are valid HTML, both trigger error correcting modes in IE, if
you're going to avoid a bug, the first thing is to have valid
fragements. IE don't use XHTML in a non-HTML user agent. It's likely
simply that the BR doesn't trigger whatever error recovery IE is doing
to be able to parse the crap you're freeding it.
Jim.
Richard Cornford
<snip>
> HTML += "\
> <label for='m-bx'>X:</label><input type='text' id='m-bx'/>\
> <label for='m-by'>Y:</label><input type='text' id='m-by'/>\
> <label for='m-bw'>Width:</label><input type='text' id='m-bw'/>\
> <label for='m-bh'>Height:</label><input type='text' id='m-bh'/>"
> HTML += "html after";
You appear to be trying to escape literal line terminators. ECMA 262
explicitly forbids that when it says (in section 7.2) "A line terminator
cannot occur within any token, note even a string literal.". So crashing
IE may be an extreme example of not working, but failing to execute
would be a reasonable expectation of this code as written.
Richard.
VK
nick...@hotmail.com wrote:
> Without knowing "html before" and "html after" can anyone fathom any
> reason why the following code crashes IE but if I add <br/> after ANY
> <input> tags it doesn't?
>
> ******************************************************
> HTML = "html before";
> <label for='m-bx'>X:</label><input type='text' id='m-bx'/>\
> <label for='m-by'>Y:</label><input type='text' id='m-by'/>\
> <label for='m-bw'>Width:</label><input type='text' id='m-bw'/>\
> <label for='m-bh'>Height:</label><input type='text' id='m-bh'/>"
> HTML += "html after";
>
> bEditor.innerHTML = HTML;
> dW.appendChild(bEditor);
> ******************************************************
<br /> has nothing to do with your problem. You simply cannot break
string literal by new lines, it's not Visual Basic here ;-)
HTML+= "<label for='m-bx'>X:</label><input type='text' id='m-bx'/>";
HTML+= "<label for='m-by'>Y:</label><input type='text' id='m-by'/>";
... will fix your problem.
nick...@hotmail.com
OK fair enough. I always thought this is pretty safe hack for a more
readable code. Obviously I had a lot of bad influence over the years :-)
Janwillem Borleffs
> You appear to be trying to escape literal line terminators. ECMA 262
> explicitly forbids that when it says (in section 7.2) "A line
> terminator cannot occur within any token, note even a string
> literal.". So crashing IE may be an extreme example of not working,
> but failing to execute would be a reasonable expectation of this code
> as written.
>
However, the following renders just fine on IE6, FF and Opera:
http://playground.jwscripts.com/js-lineseparator.php
So it appears that in some cases, line separators can be applied just
fine...
JW
VK
> However, the following renders just fine on IE6, FF and Opera:
>
> http://playground.jwscripts.com/js-lineseparator.php
>
> So it appears that in some cases, line separators can be applied just
> fine...
That is so amazin - I'm speachless! I confirm it works just fine for IE
6.0, FF 1.0.7, Opera 8.1
Of course the escape sign \ must be the very last in the string to kill
the new line terminator (or its 1st part in Windows). That could be the
issue in OP.
Naturally it means *a highly extended reading* of what string literal
means in the program code. As there are not any mentions of this in
official ECMA / JavaScript / JScript docs, I say it's an expoit of the
model behavior ambiguty rather than a new feature.
I'm just dying to know if it was possible on 4th browsers too (Dr.
Stockton, are you here?!) If so then the solution was right in front of
us all these years.
Jim Ley
>Janwillem Borleffs wrote:
>> However, the following renders just fine on IE6, FF and Opera:
>>
>> http://playground.jwscripts.com/js-lineseparator.php
>>
>> So it appears that in some cases, line separators can be applied just
>> fine...
>
>That is so amazin - I'm speachless! I confirm it works just fine for IE
>6.0, FF 1.0.7, Opera 8.1
It's worked just about everywhere always, the big difference is what
is in the string, some UA's have a \n in the string, others don't.
>I'm just dying to know if it was possible on 4th browsers too (Dr.
>Stockton, are you here?!) If so then the solution was right in front of
>us all these years.
It's been generally possible for years, it's still a bad idea, as
Richard Cornford noted, it's not part of ECMASCript, it's an
extension, and as it doesn't add anything we can already do, there's
no point taking the risk.
Jim.
Michael Winter
[Line separators in string literals]
> As there are not any mentions of this in official ECMA [...] docs
> [...]
It's mentioned three times in ECMA-262, and each time it's stated as
forbidden:
A line terminator cannot occur within any token, not even a
string.
-- par. 1, sentence 4, 7.3 - Line Terminators
Escape Sequence ::
CharacterEscapeSequence
0 [lookahead ∉ DecimalDigit]
HexEscapeSequence
UnicodeEscapeSequence
CharacterEscapeSequence ::
SingleEscapeCharacter
NonEscapeCharacter
NonEscapeCharacter ::
SourceCharacter but not EscapeCharacter or LineTerminator
-- Syntax, 7.8.4 - String Literals
Repeated in Annex A - Grammar Summary
A 'LineTerminator' character cannot appear in a string literal,
even if preceded by a backslash \. The correct way to cause a
line terminator character to be part of the string value of a
string literal is to use an escape sequence such as \n or
\u000A.
-- Note, (end of) 7.8.4 - String Literals
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
VK
Jim Ley wrote:
> It's worked just about everywhere always, the big difference is what
> is in the string, some UA's have a \n in the string, others don't.
>
> Richard Cornford noted, it's not part of ECMASCript, it's an
> extension, and as it doesn't add anything we can already do, there's
> no point taking the risk.
The referenced paragraph 7.3 of ECMA-262 doesn't deal with this
situation. It explicetly prohibits syntacs like:
(a)
var myString = "Lorem
ipsum";
// Invalid syntacs
In case such:
(b)
var myString="Lorem\
ipsum";
...it goes by the common lexical conventions rules as in paragraph 7.0
While reading the source code fragment (b) interpreter gets (for
Unix-edited text):
var
[space]
myString
=
[string literal begins]
Lorem
[new line escape sequence]
[space]
ipsum
[string literal ends]
It has no means to see that it's a "beauty new line" so the token scan
results are:
[variable]
myString
[assign]
"Lorem \n ipsum"
Same for Macintosh-edited text (with \r instead of \n)
For Windows-edited text (\r\n sequence) \r gets escaped and \n by
itself is not a line terminator, just a "trash symbol" to ignore.
So it's all perfectly ECMA-compliant (not an ECMA extention) and
actually the only way the token search can be done within the current
specifications (so FireFox acts in the same way as others).
I just never tried to read the situation in this way until this case.
VK
Michael Winter wrote:
> It's mentioned three times in ECMA-262, and each time it's stated as
> forbidden:
As I mentioned above, all these "forbiddens" are not implementable for
the situation in question, because interpreter gets not a screen
snapshot of your code but the code char sequence itself so in case of
"Lorem\
ipsum"
it sees [quot]Lorem[space][new line escape sequence][space]ipsum[quot]
and it has absolutely no means to tell what this [new line escape
sequence] stays from, so it just includes the sequence in the string
value.
The only way to fix it would be to declare illegal any line breaks
sequences until the closing quote, but it would make illegal strings
like "Lorem \n ipsum" so it is not an option.
So
"Lorem\
ipsum"
syntacs seems to be a best practice / bad practice question but not
something that could be ever prohibited/blocked by the parsing engine.
Michael Winter
> Michael Winter wrote:
>
>> It's mentioned three times in ECMA-262, and each time it's stated as
>> forbidden:
>
> As I mentioned above, all these "forbiddens" are not implementable for
> the situation in question,
Yes, they are. You did read what I quoted, right?
> because interpreter gets [...] the code char sequence itself so in case of
> "Lorem\
> ipsum"
>
> it sees [quot]Lorem[space][new line escape sequence][space]ipsum[quot]
And that 'new line escape sequence' is expressely forbidden by both the
grammar and the prose of the specification.
[snip]
> The only way to fix it would be to declare illegal any line breaks
> sequences until the closing quote
That is precisely the case. No line terminator characters are allowed
anywhere within a string literal.
> but it would make illegal strings like "Lorem \n ipsum" [...]
No, it wouldn't. That literal doesn't contain a line terminator
character. It contains an escape sequence that will be translated into a
line terminator when the string value (SV) of the literal is determined,
but that is a different matter.
Richard Cornford
And in the next 3 browsers?
Any javascript implementation following the standard will regard it as a
syntax error. It is difficult to test for language extensions that
represent syntax errors (and then conditionally act upon those tests
without exposing the unparsable code where the extension is not
supported), and there is no need to try to escape line terminators as
they are already available as escape sequences anyway. Why write
something that should break but may not in all browsers when you can
just as easily write something that has no excuse for causing problems?
Richard.