177539 - :hover and ::first-line cause duplication on :hover

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

mousing over certain links in shaver's blog sometimes causes text to duplicate

this has happened to me twice now.

I'll attach a screen shot.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot, doesn't happen all the time, but I've seen it at least twice

Comment 2

[Mike Shaver (:shaver emeritus)]

We were just talking about this the other day.  I never see it on anything but
the first para, which has both first-line: and first-letter: styles applied to 
it. See also bug 143775.

Comment 3

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

Well, at least we have a bug on this.  (If we had code-level bugzilla components
I'd push this to layout/frame construction, but I don't want to put frame
construction within style system -- it's really layout!)

Comment 4

[Andrew Schultz]

Attachment: testcase

to get the bug to happen, first mousover "big bug" and then "history profiling"


for the bug to occur the two links have to be on different lines.  the style
for a:hover must exist, but can be empty.

Comment 5

[Andrew Schultz]

regression between linux trunk builds 2002051507 and 2002051621

Comment 6

[Mike Shaver (:shaver emeritus)]

These are the checkins from the 15th and 16th: 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&sortby=Date&date=explicit&mindate=05%2F15%2F2002+00%3A00%3A00&maxdate=05%2F17%2F2002+00%3A00%3A00&cvsroot=%2Fcvsroot

There are a lot, but luckily dbaron had all the interesting-looking layout
changes, so this subset might be more useful for initial investigation:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&sortby=Date&date=explicit&mindate=05%2F15%2F2002+00%3A00%3A00&maxdate=05%2F17%2F2002+00%3A00%3A00&cvsroot=%2Fcvsroot&who=dbaron%25fas.harvard.edu&whotype=match

Comment 7

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

Almost certainly bug 140275, if it's my fault.  But I thought I fixed this
problem with bug bug 145224.  Perhaps I didn't quite get the whole thing?

Comment 8

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

Attachment: patch

This fixes the testcase, which showed the bug reliably for me before.  It's
also what I thought the problem was.  This takes advantage of the new stuff I
landed over the weekend for bug 147887.

Comment 9

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

taking

Comment 10

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

If session history weren't broken (bug 179330), I wouldn't have to do this again.

Comment 11

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

Comment on attachment 106659 [details] [diff] [review]
patch

>+          // We also need to search if the child content is an anonymous
>+          // box of any time.  (Does this mean we can eliminate one of
>+          // the other checks?)

I fixed this comment in my tree to say "type" instead of "time".

Comment 12

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

Attachment: patch

I lied.  I think we should check pseudo-elements too.

Comment 13

[Mike Shaver (:shaver emeritus)]

Comment on attachment 106661 [details] [diff] [review]
patch

>+          // We search the immediate children only, except for certain
>+          // cases where a content child could have a frame that's a
>+          // descendant but not a child:
>+          //  * if the child frame is an anonymous box or pseudo element
>+          //    of any type.
>+          //  * if the child frame has the same content pointer as its
>+          //    parent (this mostly, if not entirely, duplicates the
>+          //    previous case)
>+          //  * if the child content is anonymous and scoped to the
>+          //    parent content.

How do you feel about using the term "descendant" in that list (and perhaps in
the code as well?), since the point seems to be that the frames in question
might not be children after all?

Comment 14

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

The comment is correct as written (although perhaps a little unclear).  It's
saying that the child content's frame might not be a child frame (but an
arbitrary descendent frame) if the child frame meets certain conditions, because
those are the conditions where the child frame was constructed for something
other than content.

Comment 15

[Andrew Schultz]

I can reproduce the bug with the testcase even with patch applied
Note that you have to mouseover the first link (big bug) first and then the
second link (history profile)

Comment 16

[Andrew Schultz]

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

Comment 17

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

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

Comment 18

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

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

Comment 19

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

So when we do :first-line we create nsFirstLineFrame objects for each line
(next-in-flows of each other).  Somehow, contrary to the normal continuation
process, the ones after the first one don't get the same style context as the
first.  This is the only reason :first-line applies only to the first line
rather than all lines.  However, I can't find the logic that does this.

If I could figure out where the style context for the later line frames comes
from, I might be able to figure out how to detect such a style context (or make
it detectable), and thus fix this bug.

Comment 20

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

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

Comment 21

[Ruslan Ismailov]

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

Comment 22

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

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

Comment 23

[Martin Nepivoda]

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

Comment 24

[Sébastien Delahaye]

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

Comment 25

[Yves Lambert]

Please use http://bugzilla.mozilla.org/attachment.cgi?id=117516&action=view
and http://bugzilla.mozilla.org/attachment.cgi?id=117520&action=view
Save the files locally and update the URI of the CSS in the HTML file
This reproduce the problem everytime make sure that the text displays in  3
lines, that the style.css file is loaded and reload the page before testing.
Go to the URL i put and pass over links. this occurs sometimes with other
anchors but *always* with anchor : un lecteur de répertoire d'images, ou de BD.
I got this in netscape 7.01 phoenix; 1.2 and 1.3f


Sébastien : i didn't receive the duplicate notification of the bug.
Troumad : Please leave your page in your server.

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Boris Zbarsky [:bzbarsky]]

David, see nsFirstLineFrame::Reflow() for where the style contexts for the later
nsFirstLineFrame objects come from.

It looks like all this stuff violates the assumption that all in-flows have the
same style context; the problem could be because we have code in a few places
that makes that assumption....

Comment 28

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

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

Comment 29

[Boris Zbarsky [:bzbarsky]]

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

Comment 30

[Zibi Braniecki [:zbraniecki][:gandalf]]

WFM with Gecko/20031218 Firebird 0.7+ ... fixed?

Comment 31

[José Jeria]

With Firebird 0.8 branch build 20040114:
Hover works on the first link, but then it wont work on the second. Reloading
the page will fix the hover on the second link, but only if hovered first.

Comment 32

[Yves Lambert]

WFM (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040120
MultiZilla/1.6.1.0b)

Comment 33

[Yves Lambert]

JJ> With Firebird 0.8 branch build 20040114:
JJ> Hover works on the first link, but then it wont work on the second. Reloading
JJ> the page will fix the hover on the second link, but only if hovered first.

It is the same for me : 
http://bugzilla.mozilla.org/attachment.cgi?id=104724&action=view
the second <a> doesnot glow red every time when hovered while I cannot reproduce
a basic test case for this. 

Comment 34

[Yves Lambert]

wfm 
Mozilla 1.7b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040408 MultiZilla/1.6.3.1c

Comment 35

[Andrew Schultz]

the testcase doesn't exhibit the bug as described, but when hovering over the
second link, the hover doesn't work (the link doesn't change color).  so the bug
probably still exists, but manifests itself differently.

the behavior changed between linux trunk 2003061805 and 2003061905, probably bug
209733.  should I file a new bug?

Comment 36

[Hermann Schwab]

(In reply to comment #35)
> the testcase doesn't exhibit the bug as described, but when hovering over the
> second link, the hover doesn't work (the link doesn't change color).  so the bug
> probably still exists, but manifests itself differently.
> 
> the behavior changed between linux trunk 2003061805 and 2003061905, probably bug
> 209733.  should I file a new bug?

That is 
Bug 196249 hover effect intermittent at tigerdirect.com (categories on left-hand
side)

see testcase over there:
http://bugzilla.mozilla.org/attachment.cgi?id=130649&action=view

Comment 37

[Mike Shaver (:shaver emeritus)]

Marking FIXED, since I no longer see this in Firefox 1.5.  Yay for accidental fixed!

Comment 38

[Hixie (not reading bugmail)]

FIXED is for when we know what patch fixed it.

Comment 39

[Hixie (not reading bugmail)]

you want WORKSFORME.

Comment 40

[Mike Shaver (:shaver emeritus)]

I challenge you to a duel.