Closed Bug 42945 (TITLE) Opened 25 years ago Closed 22 years ago

Unclosed or malformed TITLE tag makes page not render

Categories

(Core :: DOM: HTML Parser, defect, P1)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: matt, Assigned: harishd)

References

Details

(4 keywords, Whiteboard: [need technote])

Attachments

(6 files, 4 obsolete files)

An HTML file with no closing TITLE tag
(deleted), text/html
Details
An HTML file with a closing TITLE tag.
(deleted), text/html
Details
Renders in Netscape 4.7 but not in Mozilla
(deleted), text/html
Details
Added 'malformed' to summary and attached a simplfied testcase to demonstrate problem with duplicate TITLE element ending tag.
(deleted), text/html
Details
Test case with <title/>
(deleted), text/html
Details
patch v1.2 [ addresses jst's concern ]
(deleted), patch
hjtoi-bugzilla
: review+
jst
: superreview+
Details | Diff | Splinter Review
If, in the HEAD part of an HTML file, there is a <TITLE> tag but no </TITLE> tag, then the page just doesn't render. I have no clue as to how Mozilla should actually act, but this doesn't seem like it. Adding two attachments which are reduced test cases.
I don't think that either Nav or IE render a page with an unclosed title tag.
OK, I did a little more experimenting, and found that Netscape 4.7 will render a non-closed TITLE tag if the opening tag is in the form of <TITLE="foo bar">. (I found this example at peapod.com). I am attaching a modified version of the testcase that should render in NS 4.7 but not in Mozilla.
moving to Parser, even though this is not a real bug, but a NavQuirk issue.
Assignee: asa → rickg
Component: Browser-General → Parser
OS: Linux → All
QA Contact: doronr → janc
Off to harish for triage, but I'm willing to mark this wontfix for 6.0. Harish?
Assignee: rickg → harishd
This is very low priority bug. Marking LATER.
Status: NEW → RESOLVED
Closed: 25 years ago
Priority: P3 → P5
Resolution: --- → LATER
Target Milestone: --- → M20
*** Bug 58677 has been marked as a duplicate of this bug. ***
*** Bug 58677 has been marked as a duplicate of this bug. ***
updated qa contact.
QA Contact: janc → bsharma
*** Bug 78137 has been marked as a duplicate of this bug. ***
*** Bug 92255 has been marked as a duplicate of this bug. ***
Getting rid of LATER.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: --- → Future
QA Contact: bsharma → moied
*** Bug 108889 has been marked as a duplicate of this bug. ***
Keywords: compat
Keywords: testcase
*** Bug 130950 has been marked as a duplicate of this bug. ***
*** Bug 148044 has been marked as a duplicate of this bug. ***
*** Bug 147972 has been marked as a duplicate of this bug. ***
*** Bug 160137 has been marked as a duplicate of this bug. ***
This has enough dupes to warrant a fix I think. It looks like it might be some tool that is producing content like |<title=some stuff here>|. IE6 can handle that. Anyone willing to work on this while Harish is on sabattical?
Keywords: helpwanted
Priority: P5 → --
Target Milestone: Future → ---
*** Bug 160183 has been marked as a duplicate of this bug. ***
[From the source of the last dupe, which I INVALIDated before RKA duped] <html> <body BGCOLOR="YELLOW"> <title="Granny's Speed Shop"> WORST HTML *EVER* If it was at least before the <body> I'd suggest automatically ending <title> at </body>, but that HTML above DESERVES not to render. I e-mailed the person listed on the page asking if he had used a tool to produce the page.
*** Bug 161889 has been marked as a duplicate of this bug. ***
Alias: TITLE
*** Bug 162804 has been marked as a duplicate of this bug. ***
*** Bug 48793 has been marked as a duplicate of this bug. ***
*** Bug 166029 has been marked as a duplicate of this bug. ***
*** Bug 167315 has been marked as a duplicate of this bug. ***
*** Bug 170276 has been marked as a duplicate of this bug. ***
From bug 170276: <title>The Straight Dope: Does smoking have any health <em>benefits?</em</title> causes Mozilla to completely fail. IE6 and NN4 display the page with the title bar reading "The Straight Dope: Does smoking have any health <em>benefits?</em"
I reopened bug 167315 to track the entire page appearing as text in the titlebar due to an unclosed title tag in body and being a possible DoS. bug 170276 is, however, not a dup of bug 167315. Having the entire page appear as text in mozilla's window title is slightly different from mozilla not displaying anything in the page or titlebar at all. It's interesting that IE6 and NN4 display bug 170276's html in the title bar, while mozilla does not, and requires different conditions to show the text in the titlebar (bug 167315, unclosed title tag in body rather than in head.)
With this many duplicates may be this should get some attention.
Status: REOPENED → ASSIGNED
Priority: -- → P3
*** Bug 172006 has been marked as a duplicate of this bug. ***
*** Bug 159425 has been marked as a duplicate of this bug. ***
Here are a list of topsites that still have problems due to malformed TITLE element tags: http://www-oss.fnal.gov/~mengel/mozbug.html http://www.gjk.cz/~xkoua01/muzika.html http://members.tripod.com/~grannys/rx7.html http://www.straightdope.com/classics/a5_096.html http://www.hallowquest.com/mantiindex.htm The bugs for these sites have all be duped to this one.
Keywords: compat → top100
Summary: Unclosed TITLE tag makes page not render → Unclosed or malformed TITLE tag makes page not render
None of those seem like top 100 sites. Proabably not even top 100,000. Has anyone even contacted them to ask they fix their error?
You're right - removed top100 keyword. CCing Susiew to see if Evangelism wants to follow on any of them
Keywords: top100
*** Bug 121531 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
*** Bug 183260 has been marked as a duplicate of this bug. ***
Attached file Test case with <title/> (deleted) —
doing this also causes document not be rendered: <title/>
Is <title/> any more valid than no closing tag? People writing XML should be doing so properly. In five days, this bug will be two and a half years old. If Mozilla and all other Gecko browsers have survived all this time without a <title> hack, and no one's cared enough to attempt a patch in these 900+ days, we mine as well close this. Somehow, I think users will continue to cope with not being able to view two Geocities pages that haven't been updated since Netscape 3 was in beta.
http://isotopes.lbl.gov/education/parent/U_iso.htm does not render correctly either. It does render in IE and Netscape. the page starts starts <title> <u isotopes </title> The above comment is however a good point. Mozilla is a decent "second browser" there is probably no reason for it to be able to see all the pages that a primary browser like IE can see.
I have to strongly contradict comment #42. Mozilla is definitely the primary browser for me and a lot of other people i know. While the behavior described in this bug is not wrong, being more lenient towards html errors would simply make it easier for users to browse the web, without having to resort to other browsers that are more error-tolerant, be they primary or secondary.
I have to strongly contradict comment #43. It's obviously completely unreasonable to expect some hippie feelgood depending-on-the-community-to-fix-the-bugs-it-reports "open source" giveaway freebie browser to work as well, robustly, or reliably as a properly-produced well-marketed professional commercial product like Microsoft's Internet Explorer. We should all lower our expectations appropriately. If a complex bug like this one (and related bugs like bug 167315) proves too hard to think about fixing, you should follow the advice of comment #42 and just close this bug. (Paul, I don't think sarcasm translates awfully well for people with English as a second language.)
Keywords: compat
I agree with comment #43 and added nsbeta1 and topembed keywords. The fact that many non-topsites sites are making this error which has such a critical result as a blank home page seems like a good case for fixing this in quirks mode.
Keywords: nsbeta1, topembed
Whiteboard: [need technote]
This bug should be squashed( way too many duplicates ).
Priority: P3 → P1
Target Milestone: --- → mozilla1.3beta
to update comment 34, here are the sites from the duplicate bugs that still don't work (not including sites designed with the sole purpose of showing this bug). http://www.ssa.gov/survivorplan/ifyou.htm <title>SSA Retirement Suite</title> <title=On your own benefits> http://members.tripod.com/~grannys/rx7.html <title="foo bar"> http://www.straightdope.com/classics/a5_096.html <title>foo <em>bar</em</title> http://www.hallowquest.com/mantiindex.htm <title>foo bar</title> <meta[...]<title> and my favorite http://isotopes.lbl.gov/education/parent/U_iso.htm <title> <i foo bar </title>
Attached patch patch v1.0 (obsolete) (deleted) — — Splinter Review
This patch handles almost all the cases except the case in http://www.straightdope.com/classics/a5_096.html. However, that's a different bug and should be handled differently.
Attached patch patch v1.0.1 (obsolete) (deleted) — — Splinter Review
Same as patch v1.0 but with minor cleanups.
Attachment #109363 - Attachment is obsolete: true
Discussed in edt. Plussing.
Keywords: topembed → topembed+
Attached patch patch v1.1 (obsolete) (deleted) — — Splinter Review
This patch addresses both unclosed and malformed TITLE.
Attachment #109369 - Attachment is obsolete: true
Attached patch patched with -uw flags - for reviewers (obsolete) (deleted) — — Splinter Review
Attachment #109789 - Flags: superreview?(jst)
Attachment #109789 - Flags: review?(heikki)
Comment on attachment 109789 [details] [diff] [review] patched with -uw flags - for reviewers >+ if (!(mFlags & (NS_DTD_FLAG_HAD_FRAMESET | NS_DTD_FLAG_HAD_BODY))) { >+ // This document is not a frameset document, however, it did not contain >+ // a body tag either. So, make one!. Note: Body tag is optional per spec.. >+ result = BuildTarget(eHTMLTag_body, eToken_start, aParser, aSink); >+ NS_ENSURE_SUCCESS(result , result); > } > if(mFlags & NS_DTD_FLAG_MISPLACED_CONTENT) { >- // Create an end table token to flush tokens off the misplaced list... >- CHTMLToken* theTableToken=NS_STATIC_CAST(CHTMLToken*,mTokenAllocator->CreateTokenOfType(eToken_end,eHTMLTag_table)); >- if(theTableToken) { >- result=HandleToken(theTableToken,mParser); >- } >+ // Looks like there is an open table Close the table tag >+ // by building a matching end target rather end table. >+ result = BuildTarget(eHTMLTag_table, eToken_end, aParser, aSink); This just doesn't make sense to me. I don't see any code that indicates that there's an open table here. To me it looks like either this code is wrong, or this needs a better explanation in the comment. There's a missing period in the comment too, just before "Close".
>This just doesn't make sense to me. I don't see any code that indicates that >there's an open table here. To me it looks like either this code is wrong, or >this needs a better explanation in the comment. There's a missing period in the >comment too, just before "Close" There is nothing wrong in this code ( may be I should comment it better). If the MISPLACED flag is set then it indicates that there is an open table in the misplaced list ( in fact I should probably rename MISPLACED to MISPLACED_TABLE or something like that ) and hence we have to close the table. In any case I do understand your concern and will try to come with a slightly different patch to make those lines in question more readable. Note: This patch does not change the existing behavior w.r.t misplaced table. That is, even before this patch we used to create an end table if the MISPLACED flag was set.
Attachment #109787 - Attachment is obsolete: true
Attachment #109789 - Attachment is obsolete: true
Attachment #109789 - Flags: superreview?(jst)
Attachment #109789 - Flags: review?(heikki)
Attachment #109841 - Flags: superreview?(jst)
Attachment #109841 - Flags: review?(heikki)
Comment on attachment 109841 [details] [diff] [review] patch v1.2 [ addresses jst's concern ] Ah, gotcha. sr=jst then. Wanna open a new bug about renaming NS_DTD_FLAG_MISPLACED_CONTENT to NS_DTD_FLAG_MISPLACED_TABLE then?
Attachment #109841 - Flags: superreview?(jst) → superreview+
*** Bug 187146 has been marked as a duplicate of this bug. ***
Attachment #109841 - Flags: review?(heikki) → review+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 151821 has been marked as a duplicate of this bug. ***
various test URLs WFM with 2003041009/win2k. verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: