[RR]:hover only applies to first line of broken text when reflow required

VERIFIED FIXED in mozilla0.9.9

Status

()

--
minor
VERIFIED FIXED
17 years ago
4 years ago

People

(Reporter: psychosos, Assigned: dbaron)

Tracking

({testcase})

Trunk
mozilla0.9.9
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
When I define that a text block should be 2.6cm (with width:2.6cm) and want to use the :hover-pseudoformat with this block then the :hover applies only to the first line of the text.
See http://193.171.249.108/~jrichter/bugzilla/ for a demo (the Copyright notice in the left; please ignore the other content of the site:)
Boris: So, is this a dupe of bug 5693?
No, :hover across split text does work in the general case, so it's something
very specific about this page.
Ok, then. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
I think I have an easier testcase for this bug. Go to the page
http://www.farbeyon.de/moz/moz1.html. There is a 'br' tag in the text of a link.
Move your mouse pointer over the line 'Cavern/3919/Horwood.html'. Actual result:
no change (only the part befor 'br' becomes bold). Expected behaviour: This part
of the link gets bold, too.

An example of Mozilla behaving correct is at
http://www.farbeyon.de/moz/moz2.html. The only difference is 'color:#ffff33'
instead of 'font-weight: bold' in 'a:hover'.

Tell me if you think this is a different bug, I will file a new one then.
(Reporter)

Comment 6

17 years ago
To Fabian: I am in no way a developer (actually i am just a stupid little user) but i would say this is the same, my description was not exact (or better, i did not research enough)
So to rephrase it: some font-formatting commands (font-weight,font-style) doesn't work with :hover if the text is broken.
Is this ok?
This problem only happens when a reflow is required for the :hover effect.  This
could happen because of "font-weight: bold" (as in the testcase) or
"border-left: 1px solid black" (which also causes the same problem).

I suspect there's something funny going on with continuing frames.
Summary: :hover doesn't work when text is broken → :hover only applies to first line of broken text when reflow required
Component: Style System → Layout
Keywords: testcase

Comment 9

17 years ago
*** Bug 103507 has been marked as a duplicate of this bug. ***
*** Bug 111228 has been marked as a duplicate of this bug. ***
At least part of bug 93104 is a duplicate of this bug.

Comment 12

17 years ago
*** Bug 115985 has been marked as a duplicate of this bug. ***
->Layout
Assignee: dbaron → attinasi
QA Contact: ian → petersen
I think this is happening because of an incorrect optimization in
FrameManager::ComputeStyleChangeFor that breaks out of the loop when the style
hint is reflow.  This ignores the fact that there could still be a style change
applying to children.
(However, what I think would be a valid optimization to repace that optimization
with would be to steal style contexts from the prev-in-flow when they exist
rather than recomputing them and ending up with multiple style contexts where
there used to be one.  At least, I think we use the same style contexts when we
split frames.)
I think this is really a style bug, as it turns out.  Setting TM optimistically.
Assignee: attinasi → dbaron
Component: Layout → Style System
QA Contact: petersen → ian
Summary: :hover only applies to first line of broken text when reflow required → [RR]:hover only applies to first line of broken text when reflow required
Target Milestone: --- → mozilla0.9.9
Commenting out the optimization that I mentioned does fix this bug.

Comment 18

17 years ago
What's the perf hit when commenting that out? Seems like if it's not much
(completely subjective) then we have a stop-gap solution until a better
optimization is in place?
It's a completely invalid optimization and it's only going to make a difference
in performance when causing style reresolution directly on an element that is split.
I think this is the same as bug 41521.
Actually, the optimization I mentioned in comment 15 should already be done by
StyleSetImpl::GetContext (although in a roundabout and slightly stronger way).

Comment 23

17 years ago
Comment on attachment 65717 [details] [diff] [review]
patch

sr=hyatt
Attachment #65717 - Flags: superreview+

Comment 24

17 years ago
Comment on attachment 65717 [details] [diff] [review]
patch

sr=hyatt
*** Bug 123497 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
could this fix bug 106344 ?

Comment 28

17 years ago
Comment on attachment 65717 [details] [diff] [review]
patch

r=attinasi
Attachment #65717 - Flags: review+
Fix checked in 2002-02-16 08:31 PDT.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 30

17 years ago
Yay! This bug WFM! :) I am verifying, but as always, re-open if you find it is
still a problem.

--> verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.