Closed Bug 151506 Opened 23 years ago Closed 23 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: 23 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: 23 years ago23 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.