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

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 http://access-mozilla.sourceforge.net/mozkeyboard.html ...with my patch for 38370 applied.

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.

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

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

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.

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 :after{content} see attachment 41412 [details] for <br> see attachment 41413 [details] for <hr>

*** 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 over.

I guess that the strange behavior of http://www.gazzetta.it (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.

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

(after an IRC chat with Hixie) Another site inserts blank lines with mouseover: http://www.ilsole24ore.com/ Pass over articles' headings, or on the red linkbar's elements near the top

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 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.

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]

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 <br>s.

I just verified that my fix for bug 71979 prevents the duplication in attachment 41412. 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].

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

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 if 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).

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.

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).

Patch Rev 1 checked in on TRUNK (with assertions): mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp revision 1.665

I wonder if this the same kinda thing that plagues bug 62556. reflowing on clicking scrollbars and changing .css made div contents..

verified