Closed Bug 151506 Opened 22 years ago Closed 22 years ago

Error in the <script> tag handling by Mozilla.

Categories

(Core :: DOM: HTML Parser, defect)

x86
Windows NT
defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: mikhailian, Assigned: harishd)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

The "script" tag can not be closed with the forward slash a la xml.

Reproducible: Always
Steps to Reproduce:
1. Create 3 files:
--start test.html--
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional">
<html> <head>
<title></title>
<script src="foobar.js" />
<script src="hello.js" >
</script>
</head>
<body>
<input type="BUTTON" onClick="a()" value="Click me" type="submit"></input>
</body> </html>
--end test.html--

--start foobar.js--
--end foobar.js--

--start hello.js--
function a(){
  alert('hello');
}
--end hello.js--

2. Now, open the test.html and click the button. Nothing happens? 
3. Open the Page Source view and see how the source is colorized.




Actual Results:  The following html code 
<script src="foobar.js" />
<script src="hello.js" >
</script>
Ignores the import of hello.js since the first <script> tag is closed
with the closing </script> tag and the contents of the second <script>
tag are simply ignored.



Expected Results:  <script src="foobar.js" />
<script src="hello.js" >
</script>
Should import both foobar.js and hello.js.

Inversely,
<script src="foobar.js" />
<script src="hello.js" />
and 
<script src="foobar.js">
<script src="hello.js">
work well and they seem to mean the same for the browser.
You will likely get SGML-ish parsing with a local .html file. If you rename it 
as XHTML it will get parsed with the XML parser - once you've tidied up a bit ;)


Browser, not engine ---> Parser
Assignee: rogerl → harishd
Component: JavaScript Engine → Parser
QA Contact: pschwartau → moied
Summary: Error in the <script> tag handling by mozilla. → Error in the <script> tag handling by Mozilla.
Invalid. You cannot close a tag by ending the opening tag with "/>" in SGML;
only in XML. If you save the file with a .html extension, or if you serve it
with MIME type 'text/html', the file is correctly being treated as an SGML-based
HTML document. If you want to use non-SGML-compatible XML features like this in
your XHTML documents, save them as .xml or .xhtml and serve them as
application/xhtml+xml.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
May I reopen? I is relatively easy to guess that Mozilla looks at the file
extension. Fine with this. But shouldn't it also look first at the DOCTYPE
declaration?

Right now, my Mozilla does not understand the test.html from the example that I
suggested while served with application/xhtml+xml Content-Type. It seems that
the xmlish parser does not like the DOCTYPE declaration. Should it be reported
as a separate bug?

Anyway, even http://www.w3.org serves xhtml pages with the Content-Type:
text/html. Thus, I can conclude that serving a xhtml file over the HTTP protocol
with text/html Content-Type should be perfectly valid, whatever extension this
file has.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> Thus, I can conclude that serving a xhtml file over the HTTP protocol
> with text/html Content-Type should be perfectly valid, whatever extension this
> file has.

From W3C Note "XHTML Media Types", section 3.1
<http://www.w3.org/TR/xhtml-media-types/#text-html>:
| XHTML1, Appendix C "HTML Compatibility Guidelines" summarizes
| design guidelines for authors who wish their XHTML documents to render on
| existing HTML user agents.  The use of 'text/html' for XHTML
| SHOULD be limited for the purpose of rendering on
| existing HTML user agents, and SHOULD be limited to
| XHTML1 documents which follow the HTML Compatibility Guidelines.

From the compatibility guidelines <http://www.w3.org/TR/xhtml1/#guidelines>:
| C.3 Element Minimization and Empty Element Content
| Given an empty instance of an element whose content model is not EMPTY
| (for example, an empty title or paragraph) do not use the minimized
| form (e.g. use <p> </p> and not <p />).

To summarize: You may only serve your XHTML document as text/html if you follow
the compatibility guidelines, which state that you should use <script
src="foobar.js"></script> rather than <script src="foobar.js" />. If you wish to
use <script src="foobar.js" /> (which is valid XHXML, but not HTML 4.01), you
should use application/xhtml+xml instead.

A little further down, the XHTML Media Types note also explicitly states the
following: "XHTML documents served as 'text/html' will not be processed as
XML". Thus Mozilla should *not* look at the DOCTYPE declaration to determine
whether the document should be treated as XML.

Do you still consider this bug valid?

> Right now, my Mozilla does not understand the test.html from the example that
> I suggested while served with application/xhtml+xml Content-Type. It seems
> that the xmlish parser does not like the DOCTYPE declaration. Should it be
> reported as a separate bug?

The reason Moz's XML parser doesn't like the DOCTYPE is because it isn't valid.
Your test.html doesn't validate at <http://validator.w3.org/>.
Jonas is correct. You want XML syntax, give us an XML MIME-type. INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → VERIFIED
*** Bug 164217 has been marked as a duplicate of this bug. ***
*** Bug 284768 has been marked as a duplicate of this bug. ***
The "solution" was to declare the bug as nonexistent, because the XHTML makes
concessions and exceptions for old browsers and you seem to interpret this as a
legitimation for not fixing the bug, retracting to these concessions.

I think this is a lame excuse for not wanting to fix what is very obviously a
problem. Rather let hundreds of web developers stumble over this bug than fixing
it once in the browser. I always thought this is Microsoft mentality.

The passages that were quoted were guidelines for web developers so that they
may not stumble over this type of problems. They were not thought as
legitimation for web browser developers to leave these type of problems existent
for ever. I think with such an attitude you are rather hindering the success of
XHTML than encouraging web developers to use the new standards.

Maybe you want to rethink your decision.
*** Bug 296919 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.