117738 - <dl> within <font> nested in <table> is ignored

Status: RESOLVED FIXED

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

Description

[William Leumas]

Any DL tags when contained within FONT within TABLE is ignored.  I dont know all
of what is handled by the quirk declarations, this may be one, but it doesn't
seem like it should be.  See URL for a sample.

Comment 1

[Richard Brodie]

Confirming on Win32, build 2002010203; same in standard or quirks mode. <DL> 
within <FONT> is invalid HTML but it was 'behaving' until a few weeks ago.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Does adding </dt> and </dd> tags as appropriate help?

Comment 3

[Richard Brodie]

> Does adding </dt> and </dd> tags as appropriate help?

Yes.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Over to parser.

Comment 5

[Neil Fraser]

*** Bug 118956 has been marked as a duplicate of this bug. ***

Comment 6

[Boris Zbarsky [:bzbarsky]]

The DOM created is:

TD > DL > DT > FONT > B > #text
                 |\_ #text
                 |\_ BR 
                  \_ #text

So there are simply no DD nodes in the content model....

Comment 7

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 8

[Richard Brodie]

*** Bug 160733 has been marked as a duplicate of this bug. ***

Comment 9

[Elmar Ludwig]

*** Bug 167699 has been marked as a duplicate of this bug. ***

Comment 10

[Elmar Ludwig]

*** Bug 150309 has been marked as a duplicate of this bug. ***

Comment 11

[Elmar Ludwig]

*** Bug 146358 has been marked as a duplicate of this bug. ***

Comment 12

[samuel]

> > Does adding </dt> and </dd> tags as appropriate help?
> Yes.
In my experience, adding </DD> and </dd> tags does not make an appreciable
difference.
<P>
Actually: It's not the <DL> that gets ignored. The <DD>s  within the <DL> simply
gets formatted wrong (it is recognized, but only the first line of the
'paragraph' is indented properly)

This happens whether the font change is initiated before a <DL> or in the middle
of the list.

I get the feeling that this is probably more of a rendering problem than a
parsing problem.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Please see comment 6.  The <dl> is fine, but all the <dd>s are stripped. And
this is indeed a parsing problem.

I recommend using DOM Inspector instead of feelings to see what the content
model looks like.  ;)

Comment 14

[samuel]

kinda interesting here: I WAS getting different results, but the difference
seems to have been that I had a second font change (a <B> in this case)
straddling the first <DT>.  This seems to have produced entirely different DOM
results:

I have two web pages with the difference being that one has the straddling
bold and the other has it inside the first DT.

http://www.bcgreen.com/tmp/test/3.75-hosting-options.html
  has the bold straddling the first <DT>
http://www.bcgreen.com/tmp/test/3.75-hosting-options-b.html
  has it proprely nested  

(In both cases, the Italics starts outside the DT)

The resulting difference is notable. After straddled the first DT, things
are (almost) parsed properly.
Without the straddling, I get results much like what was previously reported.

% diff 3.75-hosting-options.html 3.75-hosting-options-b.html
31c31
< <B><dt>
---
> <dt><B>

I'm not that good at playing with DOM results (this is the first time I've really
used it), so you're probably better off to view the pages than to have me try
and describe the differences.

In this case the interesting data is in the first table, first row second column.

With the straddled bold, the italics seem to get closed outside the DL and
reopened inside,   In this case it  the DT's and DD's are properly parsed. but
placed <b>inside</b> of the italics.

Without the straddled bold, the italics are imported into the DT's, and the DDs
are lost.  I'm guessing that the parsing problem is associated with importing
the italics inside of the enclosures.

I have a second pair of test files:
http://www.bcgreen.com/tmp/test/notab.html       and
http://www.bcgreen.com/tmp/test/notab-b.html    

In this case the version with the stradling B still nests the DT/DDs inside
of an italic enclosure (improperly). and gets rendered much as it did inside the
table (improperly but not too far off)

The version without the stradling bold on the first DT properly nests the
italics inside the  DT/DDs and renders correctly.

Comment 15

[Daniel Wang]

*** Bug 183982 has been marked as a duplicate of this bug. ***

Comment 16

[Jason Barnabe (np)]

*** Bug 216594 has been marked as a duplicate of this bug. ***

Comment 17

[Henri Sivonen (:hsivonen)]

*** Bug 276997 has been marked as a duplicate of this bug. ***

Comment 18

[Bruce Carter]

I had some foreign language characters in my DL that caused the W3C 
verification to fail, but those have been fixed.  I still get incorrect 
rendering of the DL inside the font.  The reason why I put the font inside the 
table cell in the first place is that Mozilla (and the old Netscape) forget 
font tags when you go inside tables, and default back to the horrible Times 
New Roman font.  The font tag inside the table cell ensures readability of the 
contents.  IE doesn't forget the font tag when you go inside tables, so I 
guess I could take it out and let Firefox readers suffer with Times New Roman, 
but that kind of flies in the face of accessibility for the visually impaired, 
for whom Times New Roman is a big headache.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

This patch fixes this bug and passes the parser regression tests too!

nsHTMLElement::CanAutoCloseTag() determines whether or not all of the tags down
to a given tag can be automatically closed (without affecting the general
structure of the document). Before this change, it would always descend all the
way to the bottom of the document (or stop at the index of another start tag of
the same type, which makes no particular sense to me). This was overeager to
return false, since if we have <td><a><b><a>, we disallow the automatic closing
of the first <a> because there is a <td> on the context stack.

Now, we only descend to the tag we want to close, and return false only if
there is a disallowed tag between the top of the stack and it (like
<a><table><tr><td><a>). I removed the check for <body>, since that would always
just return PR_TRUE, anyway. I also removed the check for the
thePrevTag==aChildTag since it made no sense to me, and we want to ensure that
*all* tags from the top to aIndex are OK.

Comment 20

[rbs]

Comment on attachment 170839 [details] [diff] [review]
patch v1

r=rbs, your explanation seems reasonnable.

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 170839 [details] [diff] [review]
patch v1

+  eHTMLTags thePrevTag = eHTMLTag_unknown;
+
+  for(thePos = aContext.GetCount() - 1; thePos >= aIndex; thePos--) {
+    thePrevTag = aContext.TagAt(thePos);
+
+    if (thePrevTag == eHTMLTag_applet ||
+	 thePrevTag == eHTMLTag_td) {
+	   result = PR_FALSE;
+	   break;
+    }
+  }
>   
   return result;

No need to initialize thePrevTag there as it won't be used before set to
aContext.TagAt(thePos). You could even move the declaration of thePrevTag
inside the loop.

sr=jst

Comment 22

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in. (also adjusting summary since this isn't actually an {ib}
situation since RS handling was kicking in).

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 146678 has been marked as a duplicate of this bug. ***

Comment 24

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 106503 has been marked as a duplicate of this bug. ***

Comment 25

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 152615 has been marked as a duplicate of this bug. ***

Comment 26

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 129536 has been marked as a duplicate of this bug. ***