Closed Bug 26857 Opened 25 years ago Closed 24 years ago

document.write("</SCRIPT>"); closes <SCRIPT> tag.

Categories

(Core :: DOM: HTML Parser, enhancement, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jelwell, Assigned: harishd)

References

Details

(Keywords: testcase, Whiteboard: (py8ieh:snarf test case for evil tests))

Attachments

(2 files)

minimal test case. expected result is an alert.
261 bytes, text/html
Details
WORKING attachment - Demonstrates possible problem.
286 bytes, text/html
Details 
putting </SCRIPT> anywhere after a <SCRIPT> tag (even if it's commented out). I
initially found this bug because I create a popup window ala:
<SCRIPT>
<!--
child = window.open();
child.document.write("<SCRIPT>newvar = 1;</SCRIPT>");
alert("tadah");
-->
</SCRIPT>

but the first </SCRIPT> is parsed as the closing SCRIPT tag which is wrong. In
N4.x I have to include the HTML comment tags around the JAvascript in order for
it to not parse the </SCRIPT> tag. I would think that mozilla wouldn't need the
html comments. But even with them Mozilla barfs and shows the javascript after
the first </SCRIPT> tag, instead of executing the alert command.

I imagine this is a problem on OS = all. But I can only verify WinNT 2000020708
right now.
Keywords: testcase
ignore the first test case. I posted the wrong one.
photek on #mozillazine suggested that I change my document.write to:
child.document.write("<" + "SCRIPT" + ">newvar = 1;" + "<" + "/SCRIPT" + ">");

Although this would get rid of the problem, it does not fix, nor address whether 
or not Mozilla should be parsing the first </SCRIPT> tag. And, although I am 
aware that Mozilla it not meant to be backwards compatible with Netscape 4.x 
where Netscape was incompatible with the W3C standards; I am not aware of the 
RFC for this.
The end script needs to be escaped; otherwise it's seen (in cdata) as 
terminating the script.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Check out the HTML 4.0 specs, 
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4

Notice it says, "Information that appears between comments has no special 
meaning (e.g., character references are not interpreted as such)."
If you scroll up you can see the character references link (it's the prior 
section).

Anyways, it would seem that comments should not be interpreted. Javascript seems 
to be an exception, but HTML should not be rendered for items inside comments.

"The end script needs to be escaped; otherwise it's seen (in cdata) as 
terminating the script." - or maybe Mozilla needs to parse the input 
differently - the way that both Netscape 4.61 and IE 4.0 do on my WinNT box.

I'm not ususually one to point at the past and say they're right, but in this 
case I think the html 4.0 specs agree.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
<!-- --> in javascript means that non-js browsers should forget what is inside.
This is a special case.  I think mozilla renders correctly, as nested scripts
must be bad hmtl.

the wc3 spec is for HTML, not for Java Script!

"the wc3 spec is for HTML, not for Java Script!"
This is exactly my point, there's no reason to parse JavaScript, let alone 
comments for HTML tags. I'm sure doronr knows, but does not realize that 
"</SCRIPT>" is an HTML tag - and as such is dictated by W3C standards. 
And according Mozilla shouldn't be parsing for HTML inside of a comment tag.

Mozilla correctly renders the following HTML:
<B>Big Black Text
<SCRIPT>
<!--
alert("</B>");
-->
</SCRIPT>
More Big Black Text</B>


Here's another example nearly straight out of the text book:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Untitled</title>
</head>

<body>
<SCRIPT>
<!-- alert("</SCRIPT>");
-->
</SCRIPT>
hello

</body>
</html>

http://www.w3.org/TR/html4/interact/scripts.html
Says, "The JavaScript engine allows the string "<!--" to occur at the start of a 
SCRIPT element, and ignores further characters until the end of the line."

Mozilla did not ignore futher characters until the end of the line in fact it 
recognized and parsed the </SCRIPT> and printed out: "); -->hello
This is a bug.
Severity: normal → minor
I agree that the "alter()" after <!-- should be ignored. The question is where?  
In the parser or the JS engine?

My answer would be JS engine..because in the parser land SCRIPT content is a 
CDATA.

should be treated
Typo in my previous comment.

I agree that the "alert()" after <!-- should be ignored. The question is where?  
In the parser or the JS engine?

My answer would be JS engine..because in the parser land SCRIPT content is a 
CDATA.

I agree with harish AND the spec. Reassigning to clayton to consider a remedy in 
JS land.
Assignee: rickg → clayton
Status: REOPENED → NEW
Roger, what d'ya think?  = C =
Assignee: clayton → rogerl
When the given example :

<body>
<SCRIPT>
<!-- alert("</SCRIPT>");
-->
</SCRIPT>
hello
</body>

executes, the JS engine is passed a buffer containing '<!-- alert("' which it 
ignored, as required. That's the only input passed to JS for this test case. I 
don't think it's an engine bug. finger++ :-)
This isn't a bug actually, because the "<!--" at the beginning of the JavaScript
code is not the beginning of an HTML comment tag; it is a one line JavaScript
comment equivalent to "//".

JavaScript defines that sequence of characters as a JavaScript comment marker to
make it possible for pages to hide their JS code from browsers that don't
support the language.  Browsers that do support the language, however are
correct in interpreting that sequence, when found within a block of JavaScript
code, as a one-line JavaScript comment, not an HTML comment.

That's also why the closing HTML comment tag has to be commented out as "//-->".
JavaScript does not define a special meaning for that sequence of characters, so
putting it in the JavaScript code by itself would throw an error.  The HTML
parser doesn't parse that sequence of characters as a closing HTML tag if it
considers the entire contents of the script tag to be JavaScript code.

Just because it isn't a bug, however, doesn't mean it isn't a good RFE. 
Although I haven't encountered this problem myself it seems like the kind of
thing it would be useful for the HTML or JavaScript parser to be able to
distinguish.

This information comes from JavaScript: The Definitive Guide, third edition,
Section 2.4 (p. 29-30).  Note that the ECMA Standard second edition (August 98)
does not include a reference to this type of JavaScript comment.

Changing severity to "Enhancement".
Severity: minor → enhancement
Since the JS engine isn't getting called with the complete string I think this 
belongs in Parser-land.
Assignee: rogerl → rickg
Assignee: rickg → harishd
Thanks Roger. Ok Harishd: the bug is yours. We can't send partially consumed 
javascript to the JS engine. 
What we are doing is correct, AFAICT.

The contents of the <SCRIPT>...</SCRIPT> element are CDATA. To the HTML or SGML
parser, CDATA content should only be parsed for a "</" character pair, at which
point the parser should think that the CDATA block has ended.

Thus:

   <SCRIPT>
   <!--
   child = window.open();
   child.document.write("<SCRIPT>newvar = 1;</SCRIPT>");
   alert("tadah");
   -->
   </SCRIPT>

...is equivalent to (as far as the parser is concerned):

   <SCRIPT>
   ####
   ######################
   #########################################</SCRIPT>");
   alert("tadah");
   -->
   </SCRIPT>

Thus the problem is not in JS land at all, the problem is not in Parser land
either, the problem is on the page. You should escape the forward slash like
this:

   child.document.write("<SCRIPT>newvar = 1;<\/SCRIPT>");
                                           ^^^^^^
In addition, note that SGML comments <!-- -- -- --> do NOT apply inside CDATA
blocks, so TO THE SGML PARSER, there is no comment here at all.

Note also that this cannot be an "enhancement" since the specs define this
case completely.

IMHO this should be marked INVALID. (David, do you have anything to add?)
Whiteboard: (py8ieh:snarf test case for evil tests)
This is not a bug.  A few months ago I filed a bug report about this, in case
someone wanted to implement a compatibility solution to this, suggesting that it
be marked WONTFIX.  It was marked WONTFIX as I suggested.

It's not a bug, and I think this is one of those little things that is used very
rarely on the web and would be quite a pain to emulate.
I do have a fix, sort of ;), for this problem ( quirks mode only..ofcourse ). 
But needs to be tested throughly.
Target Milestone: M16
this is an exact duplicate of 7590

*** Bug 31140 has been marked as a duplicate of this bug. ***
Am marking RESOLVED WONTFIX because this is identical to both bug 18324 and bug
21944, both of which have been marked RESOLVED WONTFIX
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Harish has a partial fix, and this bug should track that fix.  Reopening.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I've already checked in a fix ( quirks mode only ) for this problem ( illegal 
</SCRIPT> ).  David, could you please verify this? Thanx.
Okay, since nobody has responded, to my previous comment, I'm going to mark this 
bug FIXED [ to get the attention ;-) ].
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I think this broke bug 2946.
Ok, maybe it didn't. I think the problem may be that we are currently 
misdetecting compatability mode. What's the bug number for that again?

Meanwhile, here are two test cases for this issue:
   http://www.bath.ac.uk/%7Epy8ieh/m/script-cdata-closing-compat.html
   http://www.bath.ac.uk/%7Epy8ieh/m/script-cdata-closing-std.html

The first is a compat mode check, the second a standard mode check.

I am NOT marking this bug VERIFIED.

*** Bug 22483 has been marked as a duplicate of this bug. ***
Adding dependency...
Depends on: 29417
verifying, all testcases, along with some sites that didn't used to work, now work
Status: RESOLVED → VERIFIED
*** Bug 34901 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: