Don't trigger during scrolling when pointer doesn't move (was: Hover events are triggered on window scroll.)
jhiggins-thrillist opened this issue · comments
Without moving the mouse and scrolling the window, the mouse events are triggered. This happens since the mouse technically isn't moving.
@usmonster yes, of course.
Sorry, I wasn't sure if this was a bug report or feature request. :] Are you saying the hover events should not be triggered on window scroll but are? Or that they should be triggered but aren't? Can you give an example?
This should probably be a feature request.
You can see an example here: http://jsfiddle.net/jhiggins/tE4KD/
Place your mouse in the circle, and use a mouse wheel or trackpad to scroll vertically over and past the blue block. The hover events are triggered, since this script is only looking at mouse movements.
A good use of this would be to avoid painting with hover events while using something like infinite scroll.
Thanks!
Ah, I see, so if I understand correctly the feature request would be something like "change behavior (or add an option) to suppress mouse tracking when scrolling and mouse isn't actually moving" ? In other words, conditionally use event.clientX/clientY instead of (or in addition to) pageX/pageY?
I believe in most cases the current behavior is desired, but a new option for this would be useful in situations. @jhiggins-thrillist or @usmonster are you planning on submitting a pull request?
I probably won't for this one, as I don't think I'd have the resources to adequately test it. I can imagine weird things happening for certain edge cases. Still, if others would want to test a version of it, I can quickly make a fork.
Whoops, please ignore the accidental reference to issue # 11, but I forked and roughly implemented what I think @jhiggins-thrillist was requesting. Please check it out, maybe test it if you want: here.
Updated code (should actually work now) and plugged it into @jhiggins-thrillist's fiddle: http://jsfiddle.net/tE4KD/7/
Still a proof-of-concept, but I think it addresses the issue. Depending on expected behavior, though, the if (scrolling) { return; } could be moved elsewhere in the logic--e.g., if the mouse pointer is over a hoverIntented element when scrolling stops, one might want mousemove (instead of mouseenter) to trigger handlerIn.. Up for discussion.
I agree the behavior you define would in most cases be desired, but it might be tricky to implement. You'll have to account for the little amount the user could move the mouse during scrolling; the mouse is most likely moving even during scrolling.
Actually, the trickiest part of this is that there's currently a bug/browser inconsistency on WebKit/Blink browsers that would make implementing such behavior require a bit more code to work--please star the issue so it gets more attention!
It's still doable, though, and I can even reuse the same compare logic (maybe with a tiny modification) to detect mousemove intent during scrolling. Otherwise I could add a similar function to detect when scrolling is stopped and only then trigger handlerIn after the next mousemove.
Which approach/behavior seems best? (A) Detecting mouse velocity during scrolling (based on cfg.sensitivity and compare logic) and only triggering handlerIn after a certain post-scrollstart distance is reached, or (B) "pausing" hoverIntent behavior altogether until I've detected scrolling has stopped?
(Personally, I think option (B) would be more intuitive.)
I actually like that hoverIntent fails in the same way as "hover" and I feel like this should be a defect submitted against every browser in the world! :) This isn't hubris, it's just one of my pet peeves when scrolling on the internet (needing to find a happy swim lane for my cursor while scrolling).
I would argue that option (A) is more consistent with hoverIntent and how scrolling currently breaks everything. But I like option (B) more. Scrolling should block hoverIntent from calling handlerIn.
However, if the user were to stop scrolling and the cursor was resting over an item with hoverIntent, I think it should call handlerIn.