With async wheel events, we still send wheel events to the main thread but scrolling does not block on handling wheel events, so it should be smooth regardless of the jank on main thread. However, wheel events end up being queued in main thread side for a long time if the thread is busy doing something else.

Please let me know if this is bot the behavior that you expect.

That's right, my original report is wrong in that we do expect wheel events to be going to main. Eventually we should throttle or coalesce the wheel events if the main thread gets busy - but we can work out that behavior later.

The important bit now is that scrolling _should_ block on the first wheel event, but only on the first one. So we shouldn't scroll if the first wheel event is 'preventDefault()'ed. In the case above, we shouldn't be janking after the first wheel has been handled. IIRC, last we chatted about this it was likely that the timeout was too short and that we were starting a new gesture stream each time, right? Maybe all we need to do is tweak the ScrollEnd timeout?

If you keep scrolling with mouse wheel after a while the scrolling seems janky. This is because the timer based timeouts happen often and we end up with a bunch of wheel event sequences like phaseBegan, phaseChanged *n, phaseEnded. The scroll seems blocked on main thread because wheel events with phaseBegan are en-queued among other wheel events and scroll is blocked on processing of wheels with phaseBegan.
I can think of three possible solutions here:
1- Coalescing wheel events with phase changed in main thread queue.
2- Not sending non blocking wheel events to the main thread if the first one is not preventDefaulted.
3- Increasing the timeout time to have fewer number of wheel events with phaseBegan, this might be tricky since we don't break latching on mouse move.

Any preferences on which option to choose? 
 

> this might be tricky since we don't break latching on mouse move.

What's the failure scenario here, that someone will move their mouse and want to scroll on something else but we'll still be latched to the other scroller? I think our current timeout is well below the timescale of the user so I think we have some room to work with here. IMO, lets do #3 first and then #1 if we find we can't push the timeout higher.

Can we have a longer latch time, but then reduce it on mousemove?

Yeah, presumably we could do that but use a slop region so we don't reset for ~1-2 pixel jitters

Comment 6 and 7 are addressed: The timer timeout is 500ms and it expires if the mouse moves further than 10 pixels.