Closed Bug 637033 Opened 14 years ago Closed 14 years ago

Accidentally self-closing a script tag should display script code

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: marc, Unassigned)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.0.10 Windows NT Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.0.10 Windows NT Consider this: <script language="javascript" /> Some source code </script> The source SHOULD be displayed because the script tag is "/>" self-closed in error. In fact, in Firefox (at least in the build I am using) the code is hidden and even operates. Reproducible: Always Found this bug looking at the page in Safari which correctly renders the script and does not attempt to run it. This is a tantalizingly minor bug, I'll grant you, but I think it might be worth fixing so I thought you should be aware of.
Marc, was your test document treated as HTML or as XML? In HTML, there are no self-closing tags - /> is not valid in HTML, particularly if it's tag soup HTML.
Alex - doctype as follows: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Not a bug. Safari is expected to fix this when they release with their HTML5 parser.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Component: DOM: Core & HTML → HTML: Parser
QA Contact: general → parser
Resolution: --- → INVALID
Henri, respectfully, how is this not a bug? If the script tag is closed, then the following text should be displayed because it its not a script. Marc
Status: RESOLVED → UNCONFIRMED
Component: HTML: Parser → DOM: Core & HTML
Resolution: INVALID → ---
I note this function works as advertised in Chrome. The bug reported to me was that the function was not working at all in Firefox - but I am assuming that the user was using an earlier version of Firefox 3.x. This issue also affects other webkit browsers - no surprise there - but surely if a tag is closed, surely the script is invalid? The W3C validator agrees that the script is not open.
The page is served with which content-type ?
> If the script tag is closed It's not. The closing slash thing is XML syntax, but your file is HTML. The doctype doesn't matter; the parser is selected purely based on the MIME type. The W3C validator is just buggy if it claims this document is valid; if it's being served as text/html but claims an XHTML doctype, then it needs to comply with XHTML 1.0 Appendix C, which the above quoted snippet certainly doesn't do. As for Chrome, see comment 3. Chrome uses the same parser as Safari.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
Component: DOM: Core & HTML → HTML: Parser
OS: Mac OS X → All
Hardware: x86 → All
Resolution: INVALID → DUPLICATE
Version: unspecified → Trunk
The snippet was buggy in and of itself - it even missed the type argument - the point was that with MY error, my Firefox (3.6.13) executed code which was not enclosed by a script tag. My user's Firefox (version unknown at this time) did not execute the block. They filed this as a bug and I spotted it immediately on checking in Webkit (Safari 4 and Android). Presumably, this was a bug in Firefox which has since been fixed? The W3C validator says the tag closing tag is present even when the opening tag was accidentally (in my buggy code) closed. Perhaps I should file this as a bug with the W3C people? Replacing the "/>" with ">" causes the real document to validate correctly. Boris - the effect is different in Chrome 9.0.x (current as of today) and Safari Mac Version 5.0.3 (6533.19.4). Presumably, these version numbers mean more to you than they do to me. As for the XHTML header, I get that directly from my software (Coda) clearly, if there is an error there, it needs to be addressed. Either way, I rely on the error console in Firefox to tell me when I screw up - as I had here - and it didn't. I find that standard's compliant code is better: this "bug/observation" began with something "quick and dirty".
Resolution: DUPLICATE → INVALID
(In reply to comment #4) > respectfully, how is this not a bug? In text/html <foo /> is equivalent to <foo > for HTML elements. The doctype doesn't matter on this point. See http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#acknowledge-self-closing-flag The self-closing flag only has error message effects for HTML elements. It has tree shape effects only for SVG and MathML elements. > The W3C validator says the tag closing tag is present even when the opening > tag was accidentally (in my buggy code) closed. Perhaps I should file this > as a bug with the W3C people? If you have the energy, please file a bug. Don't expect them to fix it any time soon, though. (Note that there's already http://www.w3.org/Bugs/Public/show_bug.cgi?id=4514 which touches this issue but doesn't address the root problem with the W3C Validator. The root problem being that they use an XML parser for text/html content depending on doctype.) > the effect is different in Chrome 9.0.x (current as of today) and > Safari Mac Version 5.0.3 (6533.19.4). Chrome 9 and Safari 5 have different parsers. Chrome has already shipped with WebKit's new parser. There isn't yet a Safari release with the new parser and Safari 5 is using the old one. I'd expect the next major release of Safari to use the new parser that they have on WebKit trunk.
You need to log in before you can comment on or make changes to this bug.