Bugzilla

(In reply to Botond Ballo [:botond] from comment #6)
> The specific regressing patch is https://phabricator.services.mozilla.com/D163532.

This patch fixes a bug where, after zooming out, which shrinks the visual scroll range, the visual viewport offset is not re-clamped to the new scroll range in the main thread, resulting in temporarily being out of bounds.

That bug only affects cases where the zooming out is done by calling `SetResolutionAndScaleTo()` directly, rather than through APZ pinch-zoom or double-tap zoom. The test in bug 1519339 does this, and indeed I thought only tests could do this, though I now realize that the implementation of Ctrl+0 does this as well.

The reason this fix caused a regression is that it exposed another latent bug where, in the affected scenario, APZ didn't re-clamp the visual viewport offset either.

The two bugs effectively cancelled each other out by interacting in a weird way (basically, the first bug led to the main thread having an invalid visual viewport offset, which then caused the main-thread logic for trying to [preserve the relative scroll offset](https://searchfox.org/mozilla-central/rev/f40d29a11f2eb4685256b59934e637012ea6fb78/layout/generic/nsGfxScrollFrame.cpp#3400-3401) to scroll to another invalid offset, which triggered a scroll offset update to APZ, which caused APZ to take a codepath where it _does_ re-clamp the visual viewport offset). Fixing the first bug exposed the second and therefore regressed Ctrl+0 behaviour.

(In reply to Botond Ballo [:botond] from comment #6)
> The specific regressing patch is https://phabricator.services.mozilla.com/D163532.

This patch fixes a bug where, after zooming out, which shrinks the visual scroll range, the visual viewport offset is not re-clamped to the new scroll range on the main thread, resulting in the main thread's copy of the visual viewport offset temporarily being out of bounds.

That bug only affects cases where the zooming out is done by calling `SetResolutionAndScaleTo()` directly, rather than through APZ pinch-zoom or double-tap zoom. The test in bug 1519339 does this, and indeed I thought only tests could do this, though I now realize that the implementation of Ctrl+0 does this as well.

The reason this fix caused a regression is that it exposed another latent bug where, in the affected scenario, APZ didn't re-clamp the visual viewport offset either.

The two bugs effectively cancelled each other out by interacting in a weird way (basically, the first bug led to the main thread having an invalid visual viewport offset, which then caused the main-thread logic for trying to [preserve the relative scroll offset](https://searchfox.org/mozilla-central/rev/f40d29a11f2eb4685256b59934e637012ea6fb78/layout/generic/nsGfxScrollFrame.cpp#3400-3401) to scroll to another invalid offset, which triggered a scroll offset update to APZ, which caused APZ to take a codepath where it _does_ re-clamp the visual viewport offset). Fixing the first bug exposed the second and therefore regressed Ctrl+0 behaviour.