Bugzilla

I was able to get local Android test runs to work and arrive at a diagnosis of the failure of helper_overflowhidden_zoom.html. The sequence of events that leads to the failure is quite bespoke. Surprisingly, `scrollToVisual()` is not involved at all.

 * Things start to go wrong when, after having scrolled the visual viewport away from the page origin, the test zooms back out using [setResolutionAndScaleTo(1.0)](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/gfx/layers/apz/test/mochitest/helper_overflowhidden_zoom.html#67).
 * This decreases the resolution without directly modifying the visual viewport offset (in a production scenario, APZ would modify both simultaneously), resulting in a visual viewport offset stored on the main thread that's temporarily (until the next APZ repaints) out-of-bounds .
 * During this period that the main's thread copy of the visual viewport offset is out of bounds, the scroll frame is reflowed as a result of the resolution change.
    * During the reflow, the out-of-bounds value causes us to pass an inconsistent set of values to [FinishReflowForScrollbar()](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/generic/nsGfxScrollFrame.cpp#6871). Specifically, we pass aMinXY=0 and aMaxXY=0 (because the scroll range is correctly computed to be empty and positioned at the layout scroll offset of (0,0), but for aCurPosXY we pass the nonzero (out-of-bounds) visual viewport offset. This in turn causes us to set those inconsistent values as the scrollbar element's `minpos`, `maxpos`, and `curpos` attributes.
 * Those inconsistent attribute values are read in `nsSliderFrame::AttributeChanged()`, where `curpos` being larger than `maxpos` triggers a [call](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/xul/nsSliderFrame.cpp#211) to `ScrollByWhole()`, scrolling all the way to bottom of the page! (Note, this is a scroll position much further down than the initial out-of-bounds value of the visual viewport offset).
   * It is **this** call that used to be a no-op before my patch, i.e. it was handed off to APZ which ignored it because the scroll frame is `overflow:hidden`, and now with my patch triggers main-thread scrolling to the bottom of the page.

I was able to get local Android test runs to work and arrive at a diagnosis of the failure of helper_overflowhidden_zoom.html. The sequence of events that leads to the failure is quite bespoke. Surprisingly, `scrollToVisual()` is not involved at all.

 * Things start to go wrong when, after having scrolled the visual viewport away from the page origin, the test zooms back out using [setResolutionAndScaleTo(1.0)](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/gfx/layers/apz/test/mochitest/helper_overflowhidden_zoom.html#67).
 * This decreases the resolution without directly modifying the visual viewport offset (in a production scenario, APZ would modify both simultaneously), resulting in a visual viewport offset stored on the main thread that's temporarily (until the next APZ repaint) out-of-bounds .
 * During this period that the main's thread copy of the visual viewport offset is out of bounds, the scroll frame is reflowed as a result of the resolution change.
    * During the reflow, the out-of-bounds value causes us to pass an inconsistent set of values to [FinishReflowForScrollbar()](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/generic/nsGfxScrollFrame.cpp#6871). Specifically, we pass aMinXY=0 and aMaxXY=0 (because the scroll range is correctly computed to be empty and positioned at the layout scroll offset of (0,0), but for aCurPosXY we pass the nonzero (out-of-bounds) visual viewport offset. This in turn causes us to set those inconsistent values as the scrollbar element's `minpos`, `maxpos`, and `curpos` attributes.
 * Those inconsistent attribute values are read in `nsSliderFrame::AttributeChanged()`, where `curpos` being larger than `maxpos` triggers a [call](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/xul/nsSliderFrame.cpp#211) to `ScrollByWhole()`, scrolling all the way to bottom of the page! (Note, this is a scroll position much further down than the initial out-of-bounds value of the visual viewport offset).
   * It is **this** call that used to be a no-op before my patch, i.e. it was handed off to APZ which ignored it because the scroll frame is `overflow:hidden`, and now with my patch triggers main-thread scrolling to the bottom of the page.

I was able to get local Android test runs to work and arrive at a diagnosis of the failure of helper_overflowhidden_zoom.html. The sequence of events that leads to the failure is quite bespoke. Surprisingly, `scrollToVisual()` is not involved at all.

 * Things start to go wrong when, after having scrolled the visual viewport away from the page origin, the test zooms back out using [setResolutionAndScaleTo(1.0)](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/gfx/layers/apz/test/mochitest/helper_overflowhidden_zoom.html#67).
 * This decreases the resolution without directly modifying the visual viewport offset (in a production scenario, APZ would modify both simultaneously), resulting in a visual viewport offset stored on the main thread that's temporarily (until the next APZ repaint) out-of-bounds .
 * During this period that the main's thread copy of the visual viewport offset is out of bounds, the scroll frame is reflowed as a result of the resolution change.
    * During the reflow, the out-of-bounds value causes us to pass an inconsistent set of values to [FinishReflowForScrollbar()](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/generic/nsGfxScrollFrame.cpp#6871). Specifically, we pass aMinXY=0 and aMaxXY=0 (because the scroll range is correctly computed to be empty and positioned at the layout scroll offset of (0,0)), but for aCurPosXY we pass the nonzero (out-of-bounds) visual viewport offset. This in turn causes us to set those inconsistent values as the scrollbar element's `minpos`, `maxpos`, and `curpos` attributes.
 * Those inconsistent attribute values are read in `nsSliderFrame::AttributeChanged()`, where `curpos` being larger than `maxpos` triggers a [call](https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/layout/xul/nsSliderFrame.cpp#211) to `ScrollByWhole()`, scrolling all the way to bottom of the page! (Note, this is a scroll position much further down than the initial out-of-bounds value of the visual viewport offset).
   * It is **this** call that used to be a no-op before my patch, i.e. it was handed off to APZ which ignored it because the scroll frame is `overflow:hidden`, and now with my patch triggers main-thread scrolling to the bottom of the page.