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.

The modified test fails without this fix and passes with it

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.

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.