We doubly-create :before/:after content for some elements. In particular, CSS describes :before/:after content as being created as the first-child or last-child of the content to which the selectors match, not the previous sibling or next sibling. However, it gives *examples* with img:before that contradict this, so we put a hack in ConstructHTMLFrame to support :before/:after on leaf frames. This hack causes a bunch of serious problems (bugs related to HR and RemoveGeneratedContentFrameSiblings). However, since we don't check |processChildren| in ConstructHTMLFrame, we create the content the correct way too in the case where the element isn't a leaf. Testcase and patch to be attached.
This fix makes no sense to me, but it works. Hold my hand and explain why? (It would seem to me like it would preclude creating of the :before and :after content on the <legend> element itself, for example.)
If |ProcessChildren| is true, then we call ProcessChildren, which creates the generated content in the correct place, in the child list.
Adding bugs with doubled GC so they get tested when this is fixed.
Comment on attachment 81733 [details] [diff] [review] patch r=attinasi - thanks for the explanation David. Could you include a comment saying why !processChildren is used? The comment you have is interesting, but does not explain how ProcessChildren creates the generated content...
Comment on attachment 81733 [details] [diff] [review] patch sr=waterson
Fix checked in to trunk 2002-04-30 17:51 PDT.
Fixed in new Linux CVS trunk build.
Reopening since I might want this on 1.0...
Ok, never mind about the branch, unless we want it in order to land the fix for bug 141054.
VERIFIED FIXED using attachment.cgi 81730
*** Bug 168740 has been marked as a duplicate of this bug. ***