Repro:
- Use http://rbyers.net/scroll-latency.html
- Enable 'periodic jank' to 500ms
- Notice that touch scrolling can be slow to start, but is fixed by enabling 'passive'.
- Switch the touch listener type to touchend
- Try scrolling without 'passive', it's also janky
There's no good reason to block scroll start as a result of non-passive touchend listeners (since touchend doesn't block scroll). I believe this happens because the touch hit rects are a union of all touch listeners.
We've discussed this as outstanding work, but I couldn't find any bug tracking it.
This is bad because it means sites wishing to cancel just touchend (eg. to avoid the mouse events) can't avoid scroll blocking. Also the touch scroll intervention ( issue 599609 ) can probably only safely effect touchstart and touchmove listners - making touchend events uncancelable on tap would break fastclick libraries (get double click handling).
One possible simple fix is to not include touchend (and touchcancel?) listeners in the touch hit rects at all, and always send touchend events to blink (regardless of listener status). Since the touchend during a scroll is uncancelable, I don't see a big down side to this. I guess there's some risk of tap latency being higher when tapping on a location without a touch handler (but on a page that has a touch handler somewhere) - two trips to blink instead of just one. But I expect that would be minor.
Marking this Pri-1 for M52 as I think it's a pre-requisite to doing any sort of touch scrolling intervention. Thoughts?
Comment 1 by rbyers@chromium.org
, Apr 9 2016