non-passive wheel listeners are a problem for scroll performance. The problem for wheel is worse in some ways that for touchstart/touchmove because with touch at least it's just the beginning of the scroll that's blocked, not every single update. Most browsers already have some notion of a wheel sequence (group of wheel events that together "latch" to a single element, eg. based on when the users fingers actually lift from a touchpad). We could probably bring the "blocks only scroll start" property of touch events to wheel by saying that wheel events are uncancelable during a scroll (i.e. the site must cancel the first one if it wants to cancel any in a given sequence).

Off the top of my head here's the behavior of the various major browsers related to this:

• Safari: Does latching (at least for touchpad) - so that there is a defined sequence of wheel events
• Chrome: Is close to shipping latching.
• Firefox: Latches, including generating "wheel transactions" based on a timer for mouse wheels which don't themselves have defined start/end. Also makes wheel events other than the first asynchronous so that cancelation is delayed (doesn't impact the scroll caused by that wheel event, only some future one).
• Edge: Doesn't latch by default, but can be enabled with -ms-scroll-chaining: none. Doesn't send wheel events at all for high-precision touchpads.

Some day we might want to go further and try to address the first event problem (as we've done for touch in #18), but that's harder and much lower impact than this first step here.

/cc @tdresser @dtapuska who are thinking about this in blink.