Closed
Bug 153960
Opened 23 years ago
Closed 23 years ago
Parsing of HTML comments with dashes produces inconsistent results
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 144902
People
(Reporter: adam, Assigned: harishd)
References
()
Details
Attachments
(1 file)
992 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
BuildID: 2002053012
In strict mode, parser does not handle multiple dashes "-" inside an HTML
comment "<!-- -->". These are not permitted in the spec, but the results are not
consistent. This parsing can result in large quantities of the HTML not being
rendered, or most of the comment itself being rendered as text.
In the example, http://solesby.com/mozilla/comment.html, some of the text is not
displayed after the erroneous comment. In another example,
http://solesby.com/mozilla/comment2.html, the error is not handled in a
consistent fasion.
Reproducible: Always
Steps to Reproduce:
Create content with a comment that contains multiple dashes inside an HTML
comment. For example:
<!-- ---------------- bad comment --------------- -->
<h2>This text does not show up</h2>
<!-- ---------------- bad comment --------------- -->
Actual Results: The markup "<h2>...</h2>" is not rendered, presumably due to
the invalid use of dashes in the comment. Viewing the source within Mozilla
shows that the parse is treating the entire text from the first comment to the
second as a single comment.
Further tests show that depending on the errors in the second comment, the
parser handles the invalid comments differently. Sometimes it seems to make the
entire block into a single comment, others it marks most of the first comment as
text which gets rendered.
Expected Results: The spec is not clear. It seems that the valid markup should
still be rendered. This should definately be the case when the comment is easily
distinguishable, e.g. it does not contain other markup characters such as < or >
that might make it ambiguous. It does not seem consistent in its current error
handeling.
I discovered this problem working with a large site with content generated with
include files. Every include file contained a comment at the beginnig and end
that included dashes. All of the HTML were passed the validation tools used, but
the invalid comments were not detected. Upon the release of Mozilla 1.0, those
users reported many empty pages because all content between the header and
footer include files was not being rendered (treated as a comment). This seems
like something that could easily happend to a large quantity of sites.
Comment 1•23 years ago
|
||
The behaviour varies depending on the rendering mode.
(see http://www.mozilla.org/docs/web-developer/quirks/)
If the page is rendered in quirks mode, then things will behave as you expect -
comments will start at "<!--" and end at the following "-->"
If the page is triggering strict standards-compliance mode (like your examples
do, because of their DOCTYPEs), then things are rendered EXACTLY as per the spec.
See http://bugzilla.mozilla.org/show_bug.cgi?id=102127#c16
and
http://bugzilla.mozilla.org/show_bug.cgi?id=102127#c17
For a thorough description of what that means.
So, I'm afraid Moz is behaving exactly as designed. Hence this is not a bug, so
I am closing it as invalid (sorry there isn't a gentler way of putting it)
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•23 years ago
|
||
No need to be gentle or appologize. I still think there is an issue, however.
I understand now the SGML comment delimiters, --, and that there can be multiple
comments within the markup identifiers, <! and >. Thus, the content being in my
first example is correctly being treated as a comment. What I don't understand
(even after reading the information provided in the similar bug) is what is
supposed to happen to the stuff between the comments within the same markup tag?
How is it interpreted? My reasoning (without the benefit of the SGML spec) is
that it still shouldn't be displayed. In many cases it isn't.
In this new example:
http://solesby.com/mozilla/pairs.html
I have created several pairs of comments. Some of the text in between comments
is rendered, but some of it is not. Also please be sure to view the source in
Mozilla and from another source (telnet, IE) and notice that Mozilla does not
see the <! that starts line 20. I think this may be the real symptom of the bug.
Is this because the markup is never closed? If so then why does the content
below ever get rendered?
Finally, look at:
http://solesby.com/mozilla/pairs2.html
Note that closing the comment markup causes everything to work properly. So this
is a bug in the error handling.
I'm not modifying the status, I'll let you comment and re-open if you agree that
this is not working as designed. Thanks. --Adam
Reporter | ||
Comment 3•23 years ago
|
||
Just wanted to post the HTML example in addition to the URL.
Comment 4•23 years ago
|
||
> What I don't understand (even after reading the information provided in the
> similar bug) is what is supposed to happen to the stuff between the comments
> within the same markup tag? [...] My reasoning (without the benefit of the SGML
> spec) is that it still shouldn't be displayed.
Mine too. If it's inside the SGML <! [...] > delimiters, and a user-agent
doesn't know what to do with it, I think the UA should ignore it, which is
broadly what Moz is doing.
> Also please be sure to view the source in Mozilla and from another source
> (telnet, IE) and notice that Mozilla does not see the <! that starts line 20.
THAT is bug 144902 in action. For real completeness, I'm re-opening this bug to
mark it as a duplicate of that one, since your attachment 88988 [details] is a nice
demonstration of the problem.
The related bug 137628 may make interesting reading, too.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 5•23 years ago
|
||
*** This bug has been marked as a duplicate of 144902 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•