The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla12

Status

()

Core
Layout
P2
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: sicking, Assigned: bz)

Tracking

Trunk
mozilla12
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

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
Created 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.

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).

r=dbaron

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]
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1b1f449a7fe
Flags: in-testsuite+
Whiteboard: [need landing]
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/a1b1f449a7fe
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.