So it's not that we're losing the scroll position, it's that wheel ticks kick off an animation, and the reframing interrupts the animation. If you disable smooth scrolling, such that wheel ticks immediately jump to their destination, the page behaves much better, because there's nothing for the reframing to interrupt. (If you scroll faster you still see a bit of jumping, I think because the wheel events get queued, and end up behaving like a short coarse-grained animation.) Unlike in bug 1592435 and bug 1592902, we can't make the main-thread scroll updates not interrupt a wheel animation in general, because wheel animations are destination-based and a main-thread scroll update can completely change the destination. We could potentially try to make wheel animations not be destination-based, but I think that would require a nontrivial refactor to the ScrollAnimationPhysics hierarchy. Rather, I think a more realistic approach here would be to make reframes not trigger main-thread scroll updates, or at least have them only trigger updates of type `eRestore` (which are clobbered by user scrolling).
Bug 1594298 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So it's not that we're losing the scroll position, it's that wheel ticks kick off an animation, and the reframing interrupts the animation. If you disable smooth scrolling, such that wheel ticks immediately jump to their destination, the page behaves much better, because there's nothing for the reframing to interrupt. (If you scroll faster you still see a bit of jumping, I think because the wheel events get queued, and end up behaving like a short coarse-grained animation.) Unlike in bug 1592435 and bug 1592902, we can't make main-thread scroll updates not interrupt a wheel animation in general, because wheel animations are destination-based and a main-thread scroll update can completely change the destination. We could potentially try to make wheel animations not be destination-based, but I think that would require a nontrivial refactor to the ScrollAnimationPhysics hierarchy. Rather, I think a more realistic approach here would be to make reframes not trigger main-thread scroll updates, or at least have them only trigger updates of type `eRestore` (which are clobbered by user scrolling).