Bug 1682203 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This bug is indeed involving layer pixel alignment, specifically [this ClampAndAlignWithLayerPixels call in ScrollFrameHelper::ScrollToImpl](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/generic/nsGfxScrollFrame.cpp#3205).

scrollIntoView calls end up calling [this ScrollTo](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/base/PresShell.cpp#3532) function which invokes ScrollFrameHelper::ScrollToImpl.

In the same scrollIntoView call we call [PresShell()->ScrollToVisual](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/base/PresShell.cpp#3547) which is at a few line below of the `scrollTo` call. In the case of the `ScrollToVisual` we don't use ClampAndAlignWithLayerPixels at all, thus the non-alignment position will reach to the main-thread scroll position via an APZ's repaint request.

So, in short, the first scroll event is caused by alignment scroll position, the second one is caused by unalignment scroll position.
This bug is indeed involving layer pixel alignment, specifically [this ClampAndAlignWithLayerPixels call in ScrollFrameHelper::ScrollToImpl](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/generic/nsGfxScrollFrame.cpp#3205).

scrollIntoView calls end up calling [this ScrollTo](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/base/PresShell.cpp#3532) function which invokes ScrollFrameHelper::ScrollToImpl.

In the same scrollIntoView call we call [PresShell()->ScrollToVisual](https://searchfox.org/mozilla-central/rev/3067ba33c2202459aae52b7a0f7218a71fe5f7c3/layout/base/PresShell.cpp#3547) which is at a few lines below of the `scrollTo` call. In the case of the `ScrollToVisual` we don't use ClampAndAlignWithLayerPixels at all, thus the non-alignment position will reach to the main-thread scroll position via an APZ's repaint request.

So, in short, the first scroll event is caused by alignment scroll position, the second one is caused by unalignment scroll position.

Back to Bug 1682203 Comment 8