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)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 144902

People

(Reporter: adam, Assigned: harishd)

References

()

Details

Attachments

(1 file)

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.
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
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
Attached file HTML used in example
Just wanted to post the HTML example in addition to the URL.
> 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 → ---
*** This bug has been marked as a duplicate of 144902 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: