155049 - First row of table uses default font

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect)

Description

[Greg Fenton]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    20020618

If the table is wrapped inside of a FONT FACE=... tag, the first row of the
table does not use that FACE (though other rows do).


Reproducible: Always
Steps to Reproduce:
1. Go to above URL
2. See that first line of images uses Times (default) font
3. See that other rows use the requested Verdana/Sans Serif font

Actual Results:  Wrong font displayed in first row of table

Expected Results:  All rows should use Verdana/Sans Serif

Problem seen in Moz 1.0 on both Linux and Win2K

Comment 1

[Boris Zbarsky [:bzbarsky]]

To parser; we don't propagate the residual font style to the first table in that
<center>, only to the second and later ones.

Comment 2

[Tanu Mutreja]

Attachment: Converged Test Case...

Comment 3

[Tanu Mutreja]

Problem seems to be caused by CENTER tag inside FONT. As per standards Mozilla 
works fine and close the FONT tag before it starts CENTER but IE supports 
CENTER inside FONT.

I could resolve the problem with the diff pasted below but this would lead us 
to similar arguments as we have for bug#129508. However, after reading details 
for bug# 93365, diff may be worth reviewing.

Index: src/nsElementTable.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsElementTable.cpp,v
retrieving revision 3.138
diff -u -r3.138 nsElementTable.cpp
--- src/nsElementTable.cpp      27 Jun 2002 01:49:37 -0000      3.138
+++ src/nsElementTable.cpp      20 Jul 2002 13:11:23 -0000
@@ -93,7 +93,7 @@
 TagList  gDLKids={2,{eHTMLTag_dd,eHTMLTag_dt}};
 TagList  gDTKids={1,{eHTMLTag_dt}};
 TagList  gFieldsetKids={2,{eHTMLTag_legend,eHTMLTag_text}};
-TagList  gFontKids={3,{eHTMLTag_legend,eHTMLTag_table,eHTMLTag_text}}; // 
Added table to fix bug 93365
+TagList  gFontKids={4,
{eHTMLTag_legend,eHTMLTag_table,eHTMLTag_text,eHTMLTag_center}}; // Added table 
to fix bug 93365
 TagList  gFormKids={1,{eHTMLTag_keygen}};
 TagList  gFramesetKids={3,
{eHTMLTag_frame,eHTMLTag_frameset,eHTMLTag_noframes}};

Comment 4

[Greg Fenton]

Sorry, I don't understand how it can be said that "Mozilla 
works fine and close the FONT tag before it starts CENTER".

If the font did not apply to the table at all, I would understand.  However, it
does apply to all rows of the table except the first.

Maybe this is just a wording issue, but I want to make sure the fix addresses
the right problem.

Tanu, thanks for your attention to this issue!

Comment 5

[Tanu Mutreja]

Greg, if you see the source of this HTML, you would find that it has many 
tables and FONT is not applied to the first table completely. Also it can be 
confirmed by adding more rows to first table.

>Sorry, I don't understand how it can be said that "Mozilla 
>works fine and close the FONT tag before it starts CENTER".

Mozilla works fine as it's illegal to have CENTER inside FONT.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Tanu, please note that while Harish is on sabattical for a couple of months we
will most likely not be taking non-critical parser fixes. Even when he comes
back we'd like to change the parser as little as possible because of the danger
of regressions (the parser is one of the most fragile & complicated pieces of
code we have). What this means is that if you can think of a fix outside the
parser it would have a higher change of getting accepted.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (Quirks mode)

The behaviour seems to have changed since this bug was reported.
<font><center> works fine now. So does <center><table>.
<font><table> does not however, but this is how NS4, IE and Opera does it too.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #3

Well, <font face="courier"><table> should work of course and it does - even
through a <center>.  This testcase is closer to what was originally reported
and it works fine.

Comment 9

[Mats Palmgren (inactive)]

-> WORKSFORME