Closed Bug 710917 Opened 13 years ago Closed 13 years ago

Label hovering doesn't work if moving mouse from target to label


(Core :: Layout, defect, P2)






(Reporter: sicking, Assigned: bzbarsky)





(1 file)

Steps to reproduce:

1. Load data:text/html,<style>input:hover{background:lime}</style><label>label<input></label>
2. Hover label
3. Move mouse to <input>
4. Move mouse back to label

Actual results
In steps 2 and 3 the <input> turns lime
In step 4 it goes back to default white

Expected results
In steps 2-4 the <input> should be lime
Nice catch.  This is due to us stopping the walk up the tree at the common ancestor (the <label> in this case).  So we remove the state on the button, but then don't set it on anything.
Assignee: nobody → bzbarsky
Blocks: 656379
The modified test fails without this fix and passes with it
Attachment #581876 - Flags: review?(dbaron)
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Whiteboard: [need review]
Comment on attachment 581876 [details] [diff] [review]
Moving hover from a button to text in the label containing the button should keep the button's hover state.

So the fundamental problem here is that the button was in hover in two different ways (directly and via label), and we removed one of them.  It might be helpful to explain it in those terms in order to explain why this code can be asymmetric (only running for the add-state half).


Hopefully performance won't be too much of a problem.  If it is, we could store whether a node was in :hover or :active as a result of being a label's target.
Attachment #581876 - Flags: review?(dbaron) → review+
I'll update the comment.

For the performance issue, we could do that, or we could make sure the fix for bug 556743 allows us to quickly tell whether the control is labeled or not and use that...
I just thought of trying to use a separate state bit to indicate "hovered via a label", but that would fail to correctly handle the case of nested labels for the same node with the inner one leaving hover while the outer stays in hover (not that we care overmuch about that situation, I guess).
I'll land this after the branchpoint, just to be safe.
Whiteboard: [need review] → [need landing]
Flags: in-testsuite+
Whiteboard: [need landing]
Target Milestone: --- → mozilla12
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.