Using Win32 2000011708 Build. In this testcase, the CSS properties appear outside of their scope. There are various ways of making it go away, like: Adding a space at the end of a <P>, removing the global <font> tag, and removing the first <p>...</p> paragraph. This bug does not appear in IE, or Netscape 4.7 Expected Results: All 3 <hr> seperated sections should look alike. Actual Results: Due to a font-size: of over 100%, each section gets larger and larger and has properties of previous CSS tags.

Rick, this is definitely a strange parser problem! It requires a <font> tag, a <p> tag, and a comment with no surrounding whitespace, as well as some even more contrived conditions for where those elements go!!! jmraker: Very nice catch!

This ought to be a layout bug. Here is the content-model [part of ]: body@011FC52C refcount=3< Text@01210390 refcount=3<\n> font@0121066C face=Arial refcount=3< Comment@01211700 refcount=2<!-- Deleting this font tag fixes the bug --> Text@01211DE0 refcount=3<\n> > p@0121177C refcount=3< font@0121392C face=Arial refcount=3< Text@01213F40 refcount=3<testcase 4> > > Here is the content-model for the FONT tag [ in question ] ended by /FONT. That is, "<FONT FACE="Arial"><!-- Deleting this font tag fixes the bug --> </FONT><P>...": body@011F5DAC refcount=7< Text@0120F750 refcount=3<\n> font@0120F95C face=Arial refcount=3< Comment@01210970 refcount=2<!-- Deleting this font tag fixes the bug --> Text@01210B70 refcount=3<\n> > p@01210C4C refcount=3< Text@01210CB0 refcount=3<testcase 4> > Note that the models are identical.

Ooops, I take my comments back.. I did not look into the content-model properly. I do the see the problem now!!

Harish -- I don't see the problem. Can you be more specific?

The bug seems to have gone away!!! Here is the current content-model that is identical to the second model shown in comment 000-01-24 10:19: body@0203AADC refcount=3< Text@0206B7A0 refcount=3<\n> font@0206B73C face=Arial refcount=3< Comment@0206FCE0 refcount=2<!-- Deleting this font tag fixes the bug --> Text@0206FC70 refcount=3<\n> > p@0206FA6C refcount=3< Text@0203CF00 refcount=3<testcase 4> > Note: The above content-model is based on test case ( id=4305 ). Marking FIXED.

On Win32 2000022716 daily build: The bug never went away (I didn't notice it either until last week). The <HR> (in testcase 1) were indenting (they shouldn't). Today I look again, and the parser bug is now affecting every class=a and the first class=z in testcase 2.

Not closing the <SPAN> tag makes ZDNET articles look bad: http://www.zdnet.com/zdnn/stories/news/0,4586,2523934,00.html

This is causing problems on HotBot.com. See: http://staff.hotwired.com/mikeque/mozilla/red1.html

Tweaked DTD's containment logic. Attachments in comment 2000-04-09 17:46 and 2000-04-12 17:29 are slightly different from this bug. Will open a separate bug. Marking this bug FIXED.

Using Win32 Nightly build 200050208: I still see this bug in every nightly build. Please re-evaluate the status of this bug if the fix that closed this is in the nightly builds.

I see this too...mmm...wonder what happened. Reopening the bug.

Not a beta stopper... moving to M17.

With the Linux nightly 2000050908 build: The testcase now renders correctly.

Renders correctly on NT too. Marking FIXED.

updated qa contact.

Verified on build: 2001-05-29-20-Trunk platform: Win NT The test case works fine.