Closed Bug 991 Opened 26 years ago Closed 23 years ago

[DOGFOOD][4.xP] font tags containing blocks are 'badly' parsed

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: kipp, Assigned: rickg)

References

(
URL
)

Details

(Whiteboard: [PDT-]) 

Under the "Top stories" section we get different fonts than IE and
navigator...I suspect its a face/attribute problem.
Assignee: peterl → rickg
Component: Style System → Parser
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>
Status: NEW → ASSIGNED
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
Target Milestone: M6 → M7
*** 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. ***
Assignee: rickg → harishd
Status: ASSIGNED → NEW
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.
URL: my.netscape.com → http://www.bath.ac.uk/%7Epy8ieh/inter...
Summary: fonts wrong → [4.xP] font tags containing blocks are 'badly' parsed
*** 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. ***
*** 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. ***
Priority: P2 → P3
Status: NEW → ASSIGNED
Target Milestone: M8 → M9
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. ***
Blocks: 3061
*** 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.
Target Milestone: M9 → M10
*** Bug 12632 has been marked as a duplicate of this bug. ***
Target Milestone: M10 → M11
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. ***
Priority: P3 → P2
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.
Target Milestone: M11 → M12
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. ***
Target Milestone: M12 → M13
*** 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. ***
Summary: [4.xP] font tags containing blocks are 'badly' parsed → [DOGFOOD][4.xP] font tags containing blocks are 'badly' parsed
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.
Whiteboard: PDT-
Whiteboard: PDT-
Clearing PDT- for re-eval.
Whiteboard: [PDT-]
Setting to PDT- radar per more conversation.  Ok to check in to M12 tree.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Priority: P2 → P3
Resolution: FIXED → ---
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.
Assignee: harishd → rickg
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → 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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
To get it actually off of the list, somebody has to verify ...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → FIXED
Verified (Build: 0.9.3 Linux-Mandrake 8.0)
Status: RESOLVED → VERIFIED
Depends on: 995249
No longer depends on: 995249
You need to log in before you can comment on or make changes to this bug.