Under the "Top stories" section we get different fonts than IE and navigator...I suspect its a face/attribute problem.

This is a parser problem. The <FONT SIZE=-1> isn't enclosing the list items. The offending HTML: <TABLE CELLPADDING=5 CELLSPACING=0 BORDER=0 WIDTH=100% BGCOLOR=white><TR><TD> <FONT SIZE=-1> <FONT FACE="Arial, Helvetica" SIZE=-1><B><A HREF="/news/TopStories/index.html?cp=myre" TARGET=_top><FONT COLOR=000055>TOP STORIES</FONT></A></B></FONT>&nbsp;<FONT FACE="Arial, Helvetica" SIZE=-2 COLOR="#660000">(October 8, 5:38 PM)</FONT><BR> <LI><A HREF="/news/TopStories/10_08_1998.rontz1254-story-bcnewsscandal.html?cp=myre">Ho use Opens Debate On Impeachment Inquiry</A><BR> <LI><A HREF="/news/TopStories/10_08_1998.rontz1432-story-bcnewsjones.html?cp=myre">Judg e Orders Documents Unsealed In Clinton-Jones Case</A><BR> <LI><A HREF="/news/TopStories/10_08_1998.rontz1331-story-bcnewsstocks.html?cp=myre">U.S . Stocks Plunge, Technology Sector Bloodied</A><BR> </FONT> </TD></TR></TABLE>

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

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

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

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

Assigning bug to myself.

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

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

The original test page was http://my.netscape.com/ I have created a simplified test case here: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/font.html The problem can be seen with this snippet: <font> <p> Before <font> Inside </font> After </p> </font> In StrictDTD you should be refusing to cope with this at all. In CNavDTD mode you should be parsing the <font> the same way as you parse <em> (the above snippet renders "ok" using <em> instead of <font>). For example, the following: <em> <p> Hello </p> </em> ...makes the paragraph italics. However, the following: <font color="#FF0000"> <p> Hello </p> </font> ...does not make the paragraph red. This is inconsistent behaviour.

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

Another test case, this one from bug 3073: <STYLE type="text/css"> P { margin: 1em 0; display:block; } DIV { background: navy; color: white; } </STYLE> <DIV><FONT><P>Hello</P></FONT></DIV> (Remove the <font> and it displays correctly).

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

More test cases, these from bug 4956: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=10 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36 http://www.boston.com/

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

More test cases, these from bug 5859: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=110 testcase; Floating of <FONT><P><IMG> alongside <TABLE ALIGN=LEFT> http://bugzilla.mozilla.org/showattachment.cgi?attach_id=112 testcase, further simplified. P is being cleared, but shouldn't be. http://bugzilla.mozilla.org/showattachment.cgi?attach_id=113 another version; font elements now properly closed - some overlap http://bugzilla.mozilla.org/showattachment.cgi?attach_id=115 version without FONT elements; shows correct behavior http://www.browsertune.com/bt98/

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

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

Bug 1239 has an interesting complex test case that should be examined when fixing and verifying this bug.

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

Moving all residual-style related bugs to M9.

[this comment broke out of bug 8056] The problem also occurs with <b> tags. For example, the following: <b> <p> Hello </p> </b> ...does not make the paragraph bold.

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

See also bug 7823, which is not a dup but is similar.

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

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

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

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

The <tt> element demonstrates the same problem. (from bug 8103) Try also the following (from bug 8681): <font face="arial"> this is arial <pre> this is pre </pre> </font>

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

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

Moving residual-style related bugs to M10.

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

Waiting on rickg's checkin. Moving to M11.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am upping the priority of this bug, for two reasons: 1) This bug has been around a long, long time now. 2) The fact that this bug has so many dups now is surely a sign that lots and lots of people are noticing this bug and complaining about it, and would like it fixed.

Moving to M12.

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

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

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

It's not a bug, it's a feature! :) Since enclosing block elements in a font tag is illegal HTML syntax, the "purist" in me wouldn't mind seeing pages that use it "break" in the new Netscape, just to "twit" the Web authors who say "Who gives a damn if it's invalid HTML... it *works* in the popular browsers!"

Yes. Ian said: ( Additional Comments From py8ieh=bugzilla@bath.ac.uk 05/21/99 09:36 ) >In StrictDTD you should be refusing to cope with this at all. In CNavDTD mode >you should be parsing the <font> the same way as you parse <em> (the above >snippet renders "ok" using <em> instead of <font>). I agree with Ian (i.e. This should be fixed only in quirks mode).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I'm suggesting this now be a PDT+ bug. The fixes are in (controllable by a single #define), and it corrects more than 50 problems. Harish and I have been testing this code out for weeks, so it's pretty safe.

Clearing PDT- for re-eval.

Setting to PDT- radar per more conversation. Ok to check in to M12 tree.

Fixed by landing of residual style handling.

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

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

I don't believe this is fixed as of build 2000010308. See bug 22711 which was marked as a dupe of this bug. For an example, go to <http://www.techweb.com/news/> and look at the captions below the graphics for Finance, Video, etc. Font is incorrect (although some other font issues on this same page as reported by 22711 have indeed been fixed). Compare output to Communicator 4.7 or IE5. Also incorrect are the fonts used in the "Subscribe to" boxes along right-hand side of page, and the "Techweb Sites" list along lower-left side of page.

I have agree with scott, the spacing on the page he mentions doesn't look right and the original URL from this bug: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/font.html has incorrect spacing too. This is probably not a PDT anymore; I'm lowering it's priority to P3 and reopening.

rick, would you take this??

Folks -- this is getting silly. There is a legit (new) bug on techweb, which I'll open as a new bug. Bug 991 is legitimately fixed, so I'm closing it. If there are other new issues, new bugs should be written. Also: the cited page at bath.ac... has a style problem (no redness) due to the ILLEGAL html on the page. I'll talk with pierre about it. The parser is doing the right thing.

Verified.

Changing resolution back to FIXED to get this off of the most frequent bug list. This has been fixed, but was then re-resolved as INVALID after reopening.

To get it actually off of the list, somebody has to verify ...

Verified (Build: 0.9.3 Linux-Mandrake 8.0)