Skip to content

WheelHandler: Fix possible overshoot due to non-deterministic originX/Y

ivan tkachenko requested to merge work/ratijas/kf6/wheel-overshoot into master

These properties are supposed to be used for estimations of current scroll position, not for adjusting scrolling behavior.

Fixes the case where a ListView with diverse delegates (e.g. thinner section headers) "thinks" that it has negative originY near the top, so that WheelHandler stacks that on top of topMargin, and ends up clamping final scroll position to a negative offset. Interestingly, on the next scroll tick, ListView has its top delegate fully loaded, so now it shows originY as 0, and contentY as some positive number (i.e. overshoot).

Merge request reports