Web-facing PSA: stop sending mouse position updates while scrolling

[Timothy Dresser]

Patch here.

While scrolling via trackpad or mousewheel, we currently send mouse position updates every 100ms. On pages with heavy mouse handlers or :hover styles, this can cause significant amounts of scroll jank.

Sending a mouse position update includes updating :hover styles, and dispatching mousemove, mouseover, mouseenter, mouseleave, and mouseout events.

We’re planning to stop sending mouse position updates while scrolling. This aligns more closely with the behavior of Internet Explorer, Firefox, and Safari. 100ms after a scroll ends, we’ll send the mouse position update.

- Internet Explorer: Sends events / updates :hover only when the mouse actually moves, with a few exceptions for compatibility reasons. [1]

- Firefox: Sends events / updates :hover after 100ms without any scrolling, but doesn’t dispatch mousemove events unless the mouse actually moves.

- Safari: Recently switched to only sending events / updating :hover after 100ms without scrolling.

There is some chance of this breaking websites, but since it aligns us more closely with other browsers, and provides a significant performance win, we believe it’s worthwhile. This change does not involve modifying any APIs or specified behavior.

[1] According to a PM on the IE team here.

[Rick Byers]

Thanks Tim, this is great!

Can you ellaborate on the types of symptoms we might expect for "there is some chance of this breaking websites"?  I don't expect this to be very observable (eg. not likely to violate some expectations in the app), but it may result in some less-than-ideal UI in some cases, right?

[Paul Irish]

Very excited about this work.

Developer have had a messy pile of hacks to disable :hover styles during scrolls to work around this issue.

• http://www.thecssninja.com/javascript/follow-up-60fps-scroll
  
• https://plus.sandbox.google.com/+MalteUbl/posts/NsyYKenqYNP
  
• http://www.html5rocks.com/en/tutorials/speed/unnecessary-paints/#toc-scrolling
  
• https://css-tricks.com/turn-hovers-scroll/
  
• http://www.smashingmagazine.com/2013/06/10/pinterest-paint-performance-case-study/
  
• http://code.flickr.net/2013/06/04/adventures-in-jank-busting-parallax-performance-and-the-new-flickr-home-page/

This CL gives us a massive upgrade on both performance and interoperability. 

Thanks Tim!

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Emil A Eklund]

This is awesome and will make life a lot easier for web developers.
Thanks for doing this Tim!

[Nat Duca]

\o/ such excite!

[Chris Harrelson]

+1! Really looking forward to this change.

On Tue, Jun 30, 2015 at 10:19 AM, Emil A Eklund <e...@chromium.org> wrote:

This is awesome and will make life a lot easier for web developers.
Thanks for doing this Tim!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Tim Dresser]

Rick, I think you're right that in the worst case, this will just lead to some sub-par user experience.

For an example of where this changes behavior, take a look at this demo, based on the jQuery UI tooltip demo. Previously, if you scrolled with the trackpad or mousewheel, the tooltip would stick to your cursor. Now the tooltip will only move once the scroll is over.

You can see some initial results from telemetry (for a synthetic test page) here and here.

[Rick Byers]

On Tue, Jun 30, 2015 at 3:40 PM, 'Tim Dresser' via input-dev <inpu...@chromium.org> wrote:

Rick, I think you're right that in the worst case, this will just lead to some sub-par user experience.

For an example of where this changes behavior, take a look at this demo, based on the jQuery UI tooltip demo. Previously, if you scrolled with the trackpad or mousewheel, the tooltip would stick to your cursor. Now the tooltip will only move once the scroll is over.

Well, that was never really "stuck" either - jumped every 100ms.  But yes, I get your point - this is probably the extent of the the sort of degraded experience we should expect.  Thanks.

[Tim Dresser]

I've created a chrome status entry here.

[gchiac...@gmail.com]

Right now I'm relying on scroll events firing mouse events. With this update, how will developers know which elements the mouse is interacting with during scroll if the mouse events don't fire? 

[Timothy Dresser]

gchiacchieri@, can you give some additional information on the effect you're trying to implement? 

Why do you need to know which elements the mouse is over during a scroll for which the mouse is stationary?

[Glen Chiacchieri]

Pretty simple: I want a user to be able to scroll down a list and see continuous animations based on which thing their mouse is over as they're scrolling. To make it more concrete, you can think of it as updating a discrete percent meter that shows the user where they are in the list. (I'm doing this in React, so working with standard mouse events is orders easier than doing it based on scroll position.)

Have you not found any other examples of sites that rely on this behavior? It seems strange to me that I'd be the only one doing this. Is there a way to consult more directly with devs for something like this?

[Tim Dresser]

We've never supported smooth continuous animation based on mouse events while scrolling, as we previously dispatched one mouse event per 100ms. It doesn't sound like your approach would function in IE, Firefox or Safari either, at this point.

I believe that the scroll event meets your needs more closely than mouse events do. Isn't it pretty easy to listen to DOM events in a react component?

[Glen Chiacchieri]

Well, I never said the browser would support continuous animation, only that in my application I'm listening for "mouse enters DOM item in list -> my own smooth animation plays". Without mouse events firing, I guess I'll have to do my own hit-detection on scroll to see if the mouse enters or exits an element and call the event handler that the other mouse events are bound to? It feels weird that I should have to redo all this stuff browsers already do.

But you're right, testing out the other browsers, none of them seem to support what I'm trying to do. Right now, I'm wishing this was a reason to decide against what other browsers are doing instead of conforming to what they're doing, but I'm just a frustrated designer :)

[Rick Byers]

On Mon, Jul 27, 2015 at 2:24 PM, Glen Chiacchieri <gchiac...@gmail.com> wrote:

Well, I never said the browser would support continuous animation, only that in my application I'm listening for "mouse enters DOM item in list -> my own smooth animation plays". Without mouse events firing, I guess I'll have to do my own hit-detection on scroll to see if the mouse enters or exits an element and call the event handler that the other mouse events are bound to? It feels weird that I should have to redo all this stuff browsers already do.

I agree it would be nice if you could re-use the browser logic here.  But I don't think it's weird that you'd want to decide separately to invoke this logic during scrolling (content moving relative to the mouse) in contrast to physical mouse movement (mouse moving relative to content).  The performance vs. rich effect tradeoffs are completely different in those two scenarios, so we really need to stop treating them as basically the same thing (with some hacky 'throttle' to try to account for the difference). 

Unfortunately we don't have an API for you to explicitly request a synthetic mousemove event at the last seen mouse position (with all the related events / :hover updates etc.).  I'm not opposed to trying to standardize and implement such an API in the future if there was enough demand for it.

In the interim it shouldn't be too hard to write some JS that has nearly the same effect (tracking the last seen mouse position, then onscroll using elementFromPoint to invoke some callback, perhaps even dispatching synthetic mouseenter/mousemove/mouseleave events, etc.).  Such polyfill-first development is how we generally prefer to approach the standardization of new web APIs anyway.  If such a library existed and got a lot of use, that could be a good signal that the vendors would use to prioritize exposing such an API natively.