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

Status: VERIFIED FIXED

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

Description

[Rod Taylor]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Hixie (not reading bugmail)]

dbaron: this old bug has resurfaced -- although when I try this in my Win2K
debug build, I only get two colons appearing.

Comment 4

[Hixie (not reading bugmail)]

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.

Comment 5

[Sampo Syreeni]

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.

Comment 6

[basic]

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

Comment 7

[basic]

Attachment: image for elaborate testcase

Comment 8

[basic]

Attachment: elaborate testcase

Comment 9

[basic]

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

[basic]

Attachment: a better test

Comment 11

[basic]

spam ccing self

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Isn't it likely that this would be fixed by fixing bug 47149?

Comment 13

[Hixie (not reading bugmail)]

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

[basic]

Ian: could you point to a testcase where it happens to an element other than label?

Comment 15

[Hixie (not reading bugmail)]

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

[basic]

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

[Federico Giannici]

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

Comment 18

[basic]

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

[basic]

Attachment: label testcase

Comment 20

[basic]

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>

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Tuukka Tolvanen (sp3000)]

see attachment 42546 [details] for a testcase where a <br> with  
:before{content:"(:before)";}  , inside <a></a> churns out linefeeds when moused
over.

Comment 23

[Luca Fasolo]

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

Comment 24

[basic]

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

[Dave Nichols]

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

[Dave Nichols]

Attachment: testcase for IMG inside an A

Comment 27

[Jason Johnston]

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

Comment 28

[Giacomo Magnini]

(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

Comment 29

[Jason Johnston]

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?

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This was probably fixed by the fix for bug 71979.

Comment 31

[Tuukka Tolvanen (sp3000)]

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

[Jason Johnston]

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

[basic]

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

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

Comment 34

[kinmoz]

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.

Comment 35

[kinmoz]

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.

Comment 36

[basic]

Attachment: 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

[kinmoz]

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

Comment 38

[kinmoz]

Attachment: 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?

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 40

[kinmoz]

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 41

[Marc Attinasi]

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

Comment 42

[kinmoz]

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

    mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp  revision 1.665

Comment 43

[[not reading bugmail]]

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

Comment 44

[Madhur Bhatia]

verified