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

Unclosed or malformed TITLE tag makes page not render

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.3beta

People

(Reporter: matt, Assigned: harishd)

References

Details

(4 keywords, Whiteboard: [need technote])

Attachments

(6 files, 4 obsolete files)

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: 22 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: compattop100
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. ***
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) — 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) — Splinter Review
Same as patch v1.0 but with minor cleanups.
Attachment #109363 - Attachment is obsolete: true
Discussed in edt.  Plussing.
Keywords: topembedtopembed+
Attached patch patch v1.1 (obsolete) — Splinter Review
This patch addresses both unclosed and malformed TITLE.
Attachment #109369 - Attachment is obsolete: true
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: 22 years ago20 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.