Created attachment 635137 [details] [diff] [review]
This should help with the issues seen in bug 765057. I think I'll wait to land that patch until we address this.
Unfortunately, I found that if we fire our mouse events directly over a handle element, they capture the events, and that causes all the text to get selected (I imagine because they're located in a totally different part of the DOM - the same issue as bug 765072). To cope with this, I got rid of the top padding on our handles, and I'm just sending the mouse events 1px above the handles. (I was adjusting it by HANDLE_VERTICAL_MARGIN before, and that's wrong. I probably just settled on what didn't cause all the text to get selected, without actually figuring out the root issue.) I didn't find that getting rid of the padding made it harder to trigger the touch events.
I renamed HANDLE_VERTICAL_MARGIN to HANDLE_VERTICAL_OFFSET because it's just an offset used in positionHandles (it doesn't correspond to any margin), and I upped it to 10 because I found that worked better.
(In reply to Margaret Leibovic [:margaret] from comment #0)
> Unfortunately, I found that if we fire our mouse events directly over a
> handle element, they capture the events, and that causes all the text to get
> selected (I imagine because they're located in a totally different part of
> the DOM - the same issue as bug 765072).
For complete information, I tried setting pointer-events:none; on the handles, but that caused them to become unresponsive to touch events. Then I tried just dynamically setting it, and although a test click listener I added didn't fire, I still experienced the same all-text-selected problem, so I decided to give up and just try removing the padding.
Comment on attachment 635137 [details] [diff] [review]
Nice! This is working much better for me. I don't find the handles any harder to grab either; I think their shape encourages grabbing them closer to the lower half.
Uplifted to aurora as part of a roll-up patch: