** Observed with 2002-11-23 trunk build ** When you have a source like the following: =========== ... ... <UL> <strong> <LI> Line 1 <LI> Line 2 </strong> </UL> <P> Line 3: Outside the <strong> element. ... ... =========== the effect of <strong> extends to Line 3. I have seen some documents displaying mostly in bold because of this problem. There are a couple of ways to avoid this problem. 1. Close each of the 2 <LI> with </LI>. or 2. Move <strong> in front of <ul>. I'll attach a sample test case next.
This is a regression from 1.0 branch. I can see this problem in: The latest 1.0.2 branch build. The latest trunk build. but not in Mozilla 1.0 or Netscape 6.2.x builds. This is basic stuff and should be fixed as ASAP, hopefully before the next major release.
Note that once you have this problem, all text after the problem spot will be in bold type.
->Parser, not Style System.
Adding nsbeta1 to keyword.
*** Bug 263674 has been marked as a duplicate of this bug. ***
This may be related to bug 256731 (auto-closing phrase-level elements seems to be pretty broken).
*** Bug 207032 has been marked as a duplicate of this bug. ***
So in nsElementTable.cpp, I made <li> a kBlockEntity, and allowed font to contain it through gFontKids... but this changes the regression test bug7823.html since we used to allow <li> as a child of <b>, and with my change we don't. So because <b> is a kFontStyle, it was auto-closing the <li> since it could contain it <li> (see http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/nsElementTable.cpp#2166 for the gory details) and now we don't close it since kFontStyles cannot contain kBlockEntities. Note that with my change, we parse that testcase much closer to IE (it does funky things with the DOM that we don't do, since we do RS and it just seems to deal with mismatched close tags). Also, the parser regression tests exploded when I tried to run them, so I think something screwy is going on there, too, but I doubt it's related to this bug. I'll attach a patch tomorrow at some point. bz, rbs, do you have any opinions here?
Created attachment 163891 [details] [diff] [review] patch v1 This is the described patch. One style note: this file makes no attempt to respect the 80 char limit, and I don't think now is the time to start enforcing such a limit.
Comment on attachment 163891 [details] [diff] [review] patch v1 >Index: src/nsElementTable.cpp >+ /*parent,incl,exclgroups*/ kBlockEntity, kFlowEntity, kSelf, // changed this to kBlockEntity so we enable RS handling for s/this to kBlockEntity/this back to kBlockEntity/ and r=bzbarsky
Comment on attachment 163891 [details] [diff] [review] patch v1 sr=rbs
Fix checked in.
*** Bug 139689 has been marked as a duplicate of this bug. ***