Bugzilla

(In reply to Botond Ballo [:botond] from comment #3)
> At point "YYY", the main thread receives an APZ scroll update from y=549 to to y=548. I guess it's caused by the "scroll snapping near (0,548.5)".

Further investigation suggests the scroll update is not actually caused by scroll snapping. The code that prints the "scroll snapping near" log message only changes the scroll offset itself if [this branch](https://searchfox.org/mozilla-central/rev/aed442d01309eb6695c4ace1c4d8336e2d6cafc0/gfx/layers/apz/src/AsyncPanZoomController.cpp#6822) is taken, which is not the case here.

However, the value printed in the log message, 548.5, provides a clue as to what's going on. It turns out, the scroll offset is not changing in the compositor at all: it's 548.5 both at the time of the main thread scroll update of y=548, and at the time of the main thread scroll update of y=549. I verified that the value that APZ sends with the repaint request is 548.5 both times.

The reason this results in a main thread update of y=548 one time and y=549 another time is that it gets **aligned differently** by the [layer pixel alignment](https://searchfox.org/mozilla-central/rev/aed442d01309eb6695c4ace1c4d8336e2d6cafc0/layout/generic/ScrollContainerFrame.cpp#3000) code.

I haven't dug into the details of why the scroll offset gets aligned differently; but since we're looking to disable pixel alignment by default anyways (bug 1946610), I think it would make sense to do so for this test and re-enable it.

(In reply to Botond Ballo [:botond] from comment #3)
> At point "YYY", the main thread receives an APZ scroll update from y=549 to to y=548. I guess it's caused by the "scroll snapping near (0,548.5)".

Further investigation suggests the scroll update is not actually caused by scroll snapping. The code that prints the "scroll snapping near" log message only changes the scroll offset itself if [this branch](https://searchfox.org/mozilla-central/rev/aed442d01309eb6695c4ace1c4d8336e2d6cafc0/gfx/layers/apz/src/AsyncPanZoomController.cpp#6822) is taken, which is not the case here.

However, the value printed in the log message, 548.5, provides a clue as to what's going on. It turns out, the scroll offset is not changing in the compositor at all: it's 548.5 both at the time of the main thread scroll update of y=548, and at the time of the main thread scroll update of y=549. I verified that the value that APZ sends with the repaint request is 548.5 both times.

The reason this results in a main thread update of y=548 one time and y=549 another time is that it gets **aligned differently** by the [layer pixel alignment](https://searchfox.org/mozilla-central/rev/aed442d01309eb6695c4ace1c4d8336e2d6cafc0/layout/generic/ScrollContainerFrame.cpp#3000) code.

I haven't dug into the details of why the scroll offset gets aligned differently; but since we're looking to disable pixel alignment by default anyways (bug 1946610), I think it would make sense to do so for this test. I've confirmed that this makes the test pass reliably.