Last Comment Bug 141289 - :before/:after content doubled on some elements
: :before/:after content doubled on some elements
: testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
P1 normal with 1 vote (vote)
: mozilla1.1alpha
Assigned To: David Baron :dbaron: ⌚️UTC-8
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
: 168740 (view as bug list)
Depends on:
Blocks: 90649 92426
  Show dependency treegraph
Reported: 2002-04-30 12:59 PDT by David Baron :dbaron: ⌚️UTC-8
Modified: 2002-12-31 12:35 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (497 bytes, text/html)
2002-04-30 12:59 PDT, David Baron :dbaron: ⌚️UTC-8
no flags Details
patch (3.41 KB, patch)
2002-04-30 13:02 PDT, David Baron :dbaron: ⌚️UTC-8
attinasi: review+
waterson: superreview+
Details | Diff | Splinter Review

Description User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 12:59:22 PDT
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.
Comment 1 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 12:59:44 PDT
Created attachment 81730 [details]
Comment 2 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 13:02:07 PDT
Created attachment 81733 [details] [diff] [review]
Comment 3 User image Chris Waterson 2002-04-30 13:45:20 PDT
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.)
Comment 4 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 14:45:32 PDT
If |ProcessChildren| is true, then we call ProcessChildren, which creates the
generated content in the correct place, in the child list.
Comment 5 User image Christopher Hoess (gone) 2002-04-30 15:05:44 PDT
Adding bugs with doubled GC so they get tested when this is fixed.
Comment 6 User image Marc Attinasi 2002-04-30 15:46:49 PDT
Comment on attachment 81733 [details] [diff] [review]

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 7 User image Chris Waterson 2002-04-30 16:26:44 PDT
Comment on attachment 81733 [details] [diff] [review]

Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 17:59:13 PDT
Fix checked in to trunk 2002-04-30 17:51 PDT.
Comment 9 User image Christopher Hoess (gone) 2002-04-30 21:21:25 PDT
Fixed in new Linux CVS trunk build.
Comment 10 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 21:33:29 PDT
Reopening since I might want this on 1.0...
Comment 11 User image Madhur Bhatia 2002-05-17 14:29:50 PDT
cc'ing myself
Comment 12 User image David Baron :dbaron: ⌚️UTC-8 2002-05-28 07:49:32 PDT
Ok, never mind about the branch, unless we want it in order to land the fix for
bug 141054.
Comment 13 User image Hixie (not reading bugmail) 2002-05-28 09:54:21 PDT
VERIFIED FIXED using attachment.cgi 81730
Comment 14 User image David Baron :dbaron: ⌚️UTC-8 2002-09-14 19:00:14 PDT
*** Bug 168740 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.