Update APZ wheel-handling code for passive-by-default wheel listeners
Categories
(Core :: Panning and Zooming, task, P3)
Tracking
()
People
(Reporter: kats, Unassigned)
References
Details
When we added wheel event support in APZ, it was usually the case that any wheel listeners on the page didn't specify {passive: false}
. And wheel listeners were fairly frequent, so this resulted in APZ effectively falling back to synchronous scrolling for wheel events.
To improve this situation, we made it so that we only waited for the content response on the first wheel event in a transaction (as opposed to every single wheel event), and if that first wheel event wasn't preventDefault()
ed, then we did async scrolling on all the events in that transaction. We also had code to terminate the transaction if some later wheel event in the transaction got preventDefault()
ed. This meant that the exact event that got prevented still triggered async scrolling, but we would break the transaction and give web content an opportunity to prevent async scrolling on the next transaction. (See bug 1013412)
The idea here was that in most cases, content will either be preventDefault()
ing all the wheel events, or none of them. And both of those scenarios would work correctly. If content randomly chose some wheel events to preventDefault()
then that wouldn't work so great as those would mostly get ignored. However this was an acceptable compromise and as far as I know we haven't had any issues reported by this causing problems in the wild.
However, with bug 1673278 root wheel event listeners will be marked passive by default. This should greatly reduce the number of listeners that APZ needs to care about, and so we can consider eliminating the above "compromise" code and just do the right thing of always waiting for web content for each wheel event when there's a non non-passive listener registered. This should improve correctness at the cost of doing more "sync" scrolling (where APZ needs to wait for the content response on every wheel event).
I'll mark this P3/S3 since our behaviour thus far hasn't really caused problems.
Description
•