Closed Bug 69398 Opened 24 years ago Closed 23 years ago

{label,hr,br}:after {content: ":"} repeats creation of : with mouse movement


(Core :: CSS Parsing and Computation, defect, P2)






(Reporter: rbt, Assigned: kinmoz)




(Keywords: testcase, Whiteboard: [Hixie-P2] fixed on trunk)


(4 files, 4 obsolete files)

The below CSS code:

label:after {content: ":"}

creates more and more :'s with the movement of the mouse in the area of the 
label.  The action will eventually crash Galeon on FreeBSD, and Netscape 6 on 
Windows 2000.

See (left hand menu) as an easily reproducable example.
Attached file Minimal testcase (obsolete) —
This seems to happen for all HTML elements which have content: assigned to them
using the :after pseudoclass.  Confirming, linux build 2001-02-19-08
Ever confirmed: true
Keywords: testcase
dbaron: this old bug has resurfaced -- although when I try this in my Win2K
debug build, I only get two colons appearing.
This blocks my fix for bug 38370, as can be seen at
...with my patch for 38370 applied.
Blocks: 38370
Whiteboard: [Hixie-P3]
Seen this one too. And it really does happen far more than one time. Since this
is needed to implement forced linefeeds in styled XML, and repeated addition of
linefeeds *really* wrecks a page, I too think this is a major one.
Blocks: 71979
Whiteboard: [Hixie-P3] → [Hixie-P2]
with "trunk" build 2001070108 win32, this bug *only* affects <label> and nothing
else. I'll attach a more elaborate testcase.
Attached file elaborate testcase (obsolete) —
From my testcase, I gathered that :after is implemented 2 different ways.

1. within the box (but after content) for non-replaced elements
2. after the box for replaced elements

with <label> it seems to be done within and after the box
Attached file a better test (obsolete) —
spam ccing self
Isn't it likely that this would be fixed by fixing bug 47149?
dbaron: it will fix the symptom, but i would guess not the root cause (this 
happens on more than just label, really, hence it's blocking bug 38370)
Ian: could you point to a testcase where it happens to an element other than label?
With my patch to bug 38370 (on a tree before hyatt's changes) it would happen
to any <br>. I expect you can get it to happen just by putting "\a" as the
generated content for a <br>.
Ian: would adding your patch make <br> work just like an empty <span> or a empty
<div> ? If so, I don't think this bug affects bug 38370 anymore.
if you take a look at attachment 41195 [details], I've tested
:after{content:"blahblahblah!"} on various html elements but it only appears
twice in label. Maybe hyatt fixed it in his changes.
I'm not sure, but perhaps bug 85012 could give you one more testcase...

There are 2 bugs here, one is that Mozilla displays the ':' twice for labels.
The other (related to bug 71979) is that it repeats creation of ':' with :hover
or mouseover/mousemove. I'll attach a testcase for label to show the problem.

I've yet to investigate the mouseover problem with elements other than <label>
<br> and <hr>. However I can say that only <label> causes the ':' to display twice.
Attached file label testcase
After some testing I've come to the conclusion that only <label> <br> and <hr>
are affected by the mouseover problem. <label> and <hr> repeats creation of both
:before{content} and :after{content} whereas <br> only repeats creation of

see attachment 41412 [details] for <br>
see attachment 41413 [details] for <hr>
Summary: label:after {content: ":"} repeats creation of : with mouse movement → {label,hr,br}:after {content: ":"} repeats creation of : with mouse movement
*** Bug 91068 has been marked as a duplicate of this bug. ***
see attachment 42546 [details] for a testcase where a <br> with  
:before{content:"(:before)";}  , inside <a></a> churns out linefeeds when moused
I guess that the strange behavior of

(move the mouse under "IN CHAT CON..." )

is related to this bug.

Mozilla build 2001092308, Windows NT
This is fixed for <label> since bug 47149 was fixed, but its still there for
<br> and <hr>. I'm guessing that its because those 2 are the remaining *weird*
html elements?
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011

I see this with an IMG inside an A.
Attached file testcase for IMG inside an A (obsolete) —
Attachment #25682 - Attachment is obsolete: true
Attachment #41190 - Attachment is obsolete: true
Attachment #41195 - Attachment is obsolete: true
*** Bug 103951 has been marked as a duplicate of this bug. ***
(after an IRC chat with Hixie)
Another site inserts blank lines with mouseover:

Pass over articles' headings, or on the red linkbar's elements near the top
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
The testcases no longer exhibit the mouseover bug in Win2K build 2001112104,
probably due to the fix for bug 71979 that was checked in this morning.

Can someone confirm this on other OS's?
This was probably fixed by the fix for bug 71979.
partially wfm on 200111211 trunk linux... No extra content happens on mouseovers
on, attachment 25682 [details], attachment 41190 [details], attachment 41195 [details],
attachment 41418 [details], attachment 41412 [details], attachment 41413 [details],
(couldn't find the "IN CHAT CON..." bit), attachment 54156 [details], (attachment 42546 [details] was made from this site, but it
appears the offending bits appear to have been removed at the url)

attachment 42546 [details] is the only one that still has bug, it generates "(:after)"'s
on mouseover. The css there is | .aft:after { content: "(:after)";} |, applied
to a <br class="aft"> inside an <a> element.
Ah, I didn't see that one before.  I can confirm, attachment 42546 [details] still has the
mouseover bug for me too on Win2K 2001112104.
this appears to have been fixed for <label> and <hr> but not <br>

see attachment 42546 [details] and attachment 41412 [details]

Attachment #54156 - Attachment is obsolete: true
FYI, I checked in the fix for bug 71979 at 6:30 am on 11/21 so the Win2K 
2001112104 build, which is a 4am build, that Jason used, won't have my fix for 
I just verified that my fix for bug 71979 prevents the duplication in attachment 

I see the :after duplication problem with attachment 42546 [details]. It looks like we 
need to handle an extra case where the :after frame for the <br> is pushed into 
a continuing frame for it's parent, which in this case is the <a> frame.
With build 2001112603 win32 trunk the :after box gets repeated on hover in this
testcase. Seems like the patches fixed the cases where it is contained in a
block but not when it is inline.
Taking, I have a fix for the case where the :after frame is pushed to the 
parent's next-in-flow. It fixes attachment 59181 [details] and attachment 42546 [details].
Assignee: pierre → kin
Can I get an r= and sr= for this patch?
Whiteboard: [Hixie-P2] → [Hixie-P2] FIX IN HAND, need r= and sr=
Target Milestone: mozilla0.9.8 → mozilla0.9.7
Comment on attachment 59192 [details] [diff] [review]
Patch Rev 1 (Handle case where :after frames are in parent's next-in-flow)

r=dbaron, although I wonder if any of this code risks removing something else
an :after or :before pseudo-element is dynamically added (or
the element is dynamically changed so that it matches the
selector with the pseudo-element).
Attachment #59192 - Flags: review+
To answer dbaron's question, I created a test case that allowed me to
dynamically change the class name for a given <br> and span, and it looks like
right now nsCSSFrameConstructor::AttributeChanged() is not tearing down or
creating new frames for any :before and :after pseudo content when dynamically
changing a node's class. This leaves the node's new style context and the frame
tree out of sync. <sigh> I'll file a separate bug about that.

In any case I think Patch Rev 1 is still ok.
Whiteboard: [Hixie-P2] FIX IN HAND, need r= and sr= → [Hixie-P2] FIX IN HAND, need sr=
Comment on attachment 59192 [details] [diff] [review]
Patch Rev 1 (Handle case where :after frames are in parent's next-in-flow)

sr=attinasi  (might wanna ASSERT that GetParent returns a frame, since this
won't get called on the topmost frame I think).
Attachment #59192 - Flags: superreview+
Whiteboard: [Hixie-P2] FIX IN HAND, need sr= → [Hixie-P2] FIX IN HAND, ready for checkin
Patch Rev 1 checked in on TRUNK (with assertions):

    mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp  revision 1.665
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [Hixie-P2] FIX IN HAND, ready for checkin → [Hixie-P2] fixed on trunk
I wonder if this the same kinda thing that plagues bug 62556.  reflowing on
clicking scrollbars and changing .css made div contents..
You need to log in before you can comment on or make changes to this bug.