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://18.104.22.168/~jrichter/bugzilla/ for a demo (the Copyright notice in the left; please ignore the other content of the site:)
see bug 5693
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
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.
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
*** 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.
*** Bug 115985 has been marked as a duplicate of this bug. ***
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.
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 on attachment 65717 [details] [diff] [review] patch sr=hyatt
Attachment #65717 - Flags: superreview+
*** Bug 123497 has been marked as a duplicate of this bug. ***
could this fix bug 106344 ?
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
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.