Last Comment Bug 710917 - Label hovering doesn't work if moving mouse from target to label
: Label hovering doesn't work if moving mouse from target to label
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: mozilla12
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
data:text/html,<style>input:hover{bac...
Depends on:
Blocks: 656379
  Show dependency treegraph
 
Reported: 2011-12-14 15:59 PST by Jonas Sicking (:sicking)
Modified: 2011-12-22 03:50 PST (History)
1 user (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Moving hover from a button to text in the label containing the button should keep the button's hover state. (5.13 KB, patch)
2011-12-14 21:52 PST, Boris Zbarsky [:bz]
dbaron: review+
Details | Diff | Review

Description Jonas Sicking (:sicking) 2011-12-14 15:59:11 PST
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
Comment 1 Boris Zbarsky [:bz] 2011-12-14 21:46:56 PST
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.
Comment 2 Boris Zbarsky [:bz] 2011-12-14 21:52:30 PST
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
Comment 3 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-12-16 13:34:28 PST
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.
Comment 4 Boris Zbarsky [:bz] 2011-12-16 21:15:34 PST
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...
Comment 5 Boris Zbarsky [:bz] 2011-12-16 21:59:16 PST
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).
Comment 6 Boris Zbarsky [:bz] 2011-12-16 22:00:01 PST
I'll land this after the branchpoint, just to be safe.
Comment 8 Ed Morley [:emorley] 2011-12-22 03:50:42 PST
https://hg.mozilla.org/mozilla-central/rev/a1b1f449a7fe

Note You need to log in before you can comment on or make changes to this bug.