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

RESOLVED WORKSFORME

Status

()

Core
Layout
P3
normal
RESOLVED WORKSFORME
15 years ago
12 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: dbaron)

Tracking

({regression, testcase})

Trunk
mozilla1.3alpha
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

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.
Created attachment 104651 [details]
screen shot, doesn't happen all the time, but I've seen it at least twice
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.
(Assignee)

Comment 3

15 years ago
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
(Assignee)

Updated

15 years ago

Comment 4

15 years ago
Created attachment 104724 [details]
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

15 years ago
regression between linux trunk builds 2002051507 and 2002051621
Keywords: regression
OS: Windows 2000 → All

Updated

15 years ago
Keywords: testcase
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
(Assignee)

Comment 7

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

Updated

15 years ago
QA Contact: gerardok → moied

Updated

15 years ago
Priority: -- → P4

Updated

15 years ago
Target Milestone: --- → Future
(Assignee)

Comment 8

15 years ago
Created attachment 106659 [details] [diff] [review]
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.
(Assignee)

Comment 9

15 years ago
taking
Depends on: 147887
Priority: P4 → P3
Target Milestone: Future → mozilla1.3alpha
(Assignee)

Comment 10

15 years ago
If session history weren't broken (bug 179330), I wouldn't have to do this again.
Assignee: other → dbaron
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

15 years ago
Attachment #106659 - Flags: superreview?(kin)
Attachment #106659 - Flags: review?(bzbarsky)
(Assignee)

Comment 11

15 years ago
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".
(Assignee)

Comment 12

15 years ago
Created attachment 106661 [details] [diff] [review]
patch

I lied.  I think we should check pseudo-elements too.
Attachment #106659 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #106661 - Flags: superreview?(kin)
Attachment #106661 - Flags: review?(bzbarsky)
(Assignee)

Updated

15 years ago
No longer depends on: 147887
(Assignee)

Updated

15 years ago
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?
(Assignee)

Comment 14

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

Comment 15

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

15 years ago
*** Bug 153999 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
Attachment #106661 - Attachment is obsolete: true
Attachment #106661 - Flags: superreview?(kin)
(Assignee)

Comment 17

15 years ago
*** Bug 184786 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 18

15 years ago
*** Bug 178357 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
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)
(Assignee)

Updated

15 years ago
Summary: :hover and :first-letter cause duplication on-:hover (shaver's blog) → :hover and :first-line cause duplication on-:hover (shaver's blog)
(Assignee)

Comment 19

15 years ago
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.
(Assignee)

Comment 20

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

Comment 21

15 years ago
*** Bug 191751 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

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

Comment 23

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

Comment 24

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

Comment 25

15 years ago
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....
(Assignee)

Comment 28

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

Updated

14 years ago
No longer blocks: 204100
*** Bug 212926 has been marked as a duplicate of this bug. ***

Updated

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

Comment 31

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

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

Comment 33

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

Updated

13 years ago
QA Contact: moied → ian
Hardware: PC → All
Summary: :hover and :first-line cause duplication on-:hover → :hover and ::first-line cause duplication on :hover

Comment 34

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

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

13 years ago
(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
Last Resolved: 12 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
Last Resolved: 12 years ago12 years ago
Resolution: --- → WORKSFORME
I challenge you to a duel.
You need to log in before you can comment on or make changes to this bug.