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

VERIFIED FIXED in mozilla0.9.7



18 years ago
5 years ago


(Reporter: rbt, Assigned: kinmoz)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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


(4 attachments, 4 obsolete attachments)



18 years ago
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 www.barchord.com (left hand menu) as an easily reproducable example.
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]

Comment 5

18 years ago
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]

Comment 6

18 years ago
with "trunk" build 2001070108 win32, this bug *only* affects <label> and nothing
else. I'll attach a more elaborate testcase.

Comment 7

18 years ago
Created attachment 41189 [details]
image for elaborate testcase

Comment 8

18 years ago
Created attachment 41190 [details]
elaborate testcase

Comment 9

18 years ago
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

Comment 10

18 years ago
Created attachment 41195 [details]
a better test

Comment 11

18 years ago
spam ccing self
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)

Comment 14

18 years ago
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>.

Comment 16

18 years ago
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.

Comment 17

18 years ago
I'm not sure, but perhaps bug 85012 could give you one more testcase...

Comment 18

18 years ago
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.

Comment 19

18 years ago
Created attachment 41418 [details]
label testcase

Comment 20

18 years ago
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

Comment 23

18 years ago
I guess that the strange behavior of


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

is related to this bug.

Mozilla build 2001092308, Windows NT

Comment 24

18 years ago
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?

Comment 25

18 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011

I see this with an IMG inside an A.

Comment 26

18 years ago
Created attachment 54156 [details]
testcase for IMG inside an A


18 years ago
Attachment #25682 - Attachment is obsolete: true


18 years ago
Attachment #41190 - Attachment is obsolete: true


18 years ago
Attachment #41195 - Attachment is obsolete: true

Comment 27

18 years ago
*** Bug 103951 has been marked as a duplicate of this bug. ***

Comment 28

18 years ago
(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


18 years ago
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7


18 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 29

18 years ago
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?
partially wfm on 200111211 trunk linux... No extra content happens on mouseovers
on www.barchord.com, attachment 25682 [details], attachment 41190 [details], attachment 41195 [details],
attachment 41418 [details], attachment 41412 [details], attachment 41413 [details], http://www.gazzetta.it
(couldn't find the "IN CHAT CON..." bit), attachment 54156 [details],
http://www.ilsole24ore.com/ (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.

Comment 32

18 years ago
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.

Comment 33

18 years ago
this appears to have been fixed for <label> and <hr> but not <br>

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


18 years ago
Attachment #54156 - Attachment is obsolete: true

Comment 34

18 years ago
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 

Comment 35

18 years ago
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.

Comment 36

18 years ago
Created attachment 59181 [details]
testcase with hr in link and br in link

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.

Comment 37

18 years ago
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

Comment 38

18 years ago
Created attachment 59192 [details] [diff] [review]
Patch Rev 1 (Handle case where :after frames are in parent's next-in-flow)

Can I get an r= and sr= for this patch?


18 years ago
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+

Comment 40

18 years ago
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 41

18 years ago
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+


18 years ago
Whiteboard: [Hixie-P2] FIX IN HAND, need sr= → [Hixie-P2] FIX IN HAND, ready for checkin

Comment 42

18 years ago
Patch Rev 1 checked in on TRUNK (with assertions):

    mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp  revision 1.665
Last Resolved: 18 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..

Comment 44

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