Closed Bug 98783 Opened 23 years ago Closed 23 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: psychosos, Assigned: dbaron)

References

Details

(Keywords: testcase)

Attachments

(2 files)

simple testcase
650 bytes, text/html
Details
patch
915 bytes, patch
attinasi
: review+
hyatt
: superreview+
Details | Diff | Splinter Review 
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
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
Keywords: testcase
*** 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. ***
->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.
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+
Comment on attachment 65717 [details] [diff] [review]
patch

sr=hyatt
*** 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
Closed: 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: