Closed Bug 177539 Opened 22 years ago Closed 19 years ago

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

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.3alpha

People

(Reporter: sspitzer, Assigned: dbaron)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 2 obsolete files)

screen shot, doesn't happen all the time, but I've seen it at least twice
10.77 KB, image/gif
Details
testcase
570 bytes, text/html
Details 
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.
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.
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!)
Assignee: asa → other
Component: Browser-General → Layout
QA Contact: asa → gerardok
Attached file 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.
regression between linux trunk builds 2002051507 and 2002051621
Keywords: regression
OS: Windows 2000 → All
Keywords: testcase
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?
QA Contact: gerardok → moied
Priority: -- → P4
Target Milestone: --- → Future
Attached patch patch (obsolete) — — Splinter Review 
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.
taking
Depends on: 147887
Priority: P4 → P3
Target Milestone: Future → mozilla1.3alpha
If session history weren't broken (bug 179330), I wouldn't have to do this again.
Assignee: other → dbaron
Status: NEW → ASSIGNED
Attachment #106659 - Flags: superreview?(kin)
Attachment #106659 - Flags: review?(bzbarsky)
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".
Attached patch patch (obsolete) — — Splinter Review 
I lied.  I think we should check pseudo-elements too.
Attachment #106659 - Attachment is obsolete: true
Attachment #106661 - Flags: superreview?(kin)
Attachment #106661 - Flags: review?(bzbarsky)
Attachment #106659 - Flags: superreview?(kin)
Attachment #106659 - Flags: review?(bzbarsky)
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?
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.
Attachment #106661 - Flags: review?(bzbarsky) → review+
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)
*** Bug 153999 has been marked as a duplicate of this bug. ***
Attachment #106661 - Attachment is obsolete: true
Attachment #106661 - Flags: superreview?(kin)
*** Bug 184786 has been marked as a duplicate of this bug. ***
*** Bug 178357 has been marked as a duplicate of this bug. ***
Summary: mousing over certain links in shaver's blog sometimes causes text to duplicate → :hover and :first-letter cause duplication on-:hover (shaver's blog)
Summary: :hover and :first-letter cause duplication on-:hover (shaver's blog) → :hover and :first-line cause duplication on-:hover (shaver's blog)
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.
*** Bug 189837 has been marked as a duplicate of this bug. ***
*** Bug 191751 has been marked as a duplicate of this bug. ***
*** Bug 155046 has been marked as a duplicate of this bug. ***
*** Bug 197861 has been marked as a duplicate of this bug. ***
*** Bug 197898 has been marked as a duplicate of this bug. ***
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.

*** Bug 203453 has been marked as a duplicate of this bug. ***
Blocks: 204100
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....
*** Bug 204100 has been marked as a duplicate of this bug. ***
No longer blocks: 204100
*** Bug 212926 has been marked as a duplicate of this bug. ***
URL: http://off.net/~shaver/diary/
Summary: :hover and :first-line cause duplication on-:hover (shaver's blog) → :hover and :first-line cause duplication on-:hover
WFM with Gecko/20031218 Firebird 0.7+ ... fixed?
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.
WFM (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040120
MultiZilla/1.6.1.0b)
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.
QA Contact: moied → ian
Hardware: PC → All
Summary: :hover and :first-line cause duplication on-:hover → :hover and ::first-line cause duplication on :hover
wfm 
Mozilla 1.7b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040408 MultiZilla/1.6.3.1c
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?
(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
Marking FIXED, since I no longer see this in Firefox 1.5.  Yay for accidental fixed!
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
FIXED is for when we know what patch fixed it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
you want WORKSFORME.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: