Bugzilla

Here's what's happening on this page:

  * The page has a content size of (1980.03, 1790.15) CSS pixels, and a layout viewport size of (1440, 1790.15). The page is `overflow-x: hidden`, so the layout viewport cannot be horizontally scrolled via user input.
  * When zoomed out as far as possible, the zoom level is ~0.858. The composition bounds on my phone is (1080, 1536) screen pixels, leading to a visual viewport size of (1258.74, 1790.21) CSS pixels. **Observe how this is a fraction of a pixel taller than the layout viewport due to rounding error.**
  * The visual viewport is legitimately horizontally scrollable within the layout viewport. When the user scrolls it to the right, the horizontal visual viewport offset increases from 0 to some larger value, say 100.
  * We then run the logic in `KeepLayoutViewportEnclosingVisualViewport`, which is described as follows:
```
    // If visual viewport size is greater than the layout viewport, move the
    // layout viewport such that it remains inside the visual viewport. Otherwise,
    // move the layout viewport such that the visual viewport is contained
    // inside the layout viewport.
```
  * To determine which of these is the case, we test whether the visual viewport is smaller than the layout viewport in both dimensions. **Due to the rounding error mentioned above, the check for the vertical dimension fails.** We do have a `FuzzyEqualsMultiplicative` check, but the difference here is too large for it.
  * Therefore, we attempt to do the second thing, "move the layout viewport such that the visual viewport is contained inside it", which results in **increasing the layout viewport offset to 100 as well**.
  * [Layout grumbles about APZ moving the layout viewport in an `overflow: hidden` dimension, but accepts in nonetheless.](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/apz/util/APZCCallbackHelper.cpp#124).
  * When layout recomputes the APZ scrollable rect, [its origin is the new layout viewport offset](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/layout/base/nsLayoutUtils.cpp#8450), which is now 100 horizontally.
  * As far as APZ is concerned, the allowable scrollable range for the page is now (100,0,1440,1790.15), rather than (0,0,1440,1790.15). That is, 100 on the left side of the page just became inaccessible.
  * If you're still at this zoom level, you can scroll back there via the same process, but if you zoom in, the visual viewport is now properly contained inside the layout viewport, so the ability to sneakily async-scroll the layout viewport out of bounds is lost, and the [0,100] range is truly inaccessible until you zoom back out.

Here's what's happening on this page:

  * The page has a content size of (1980.03, 1790.15) CSS pixels, and a layout viewport size of (1440, 1790.15). The page is `overflow-x: hidden`, so the layout viewport cannot be horizontally scrolled via user input.
  * When zoomed out as far as possible, the zoom level is ~0.858. The composition bounds on my phone is (1080, 1536) screen pixels, leading to a visual viewport size of (1258.74, 1790.21) CSS pixels. **Observe how this is a fraction of a pixel taller than the layout viewport due to rounding error.**
  * The visual viewport is legitimately horizontally scrollable within the layout viewport. When the user scrolls it to the right, the horizontal visual viewport offset increases from 0 to some larger value, say 100.
  * We then run the logic in `KeepLayoutViewportEnclosingVisualViewport`, which is described as follows:
```
    // If visual viewport size is greater than the layout viewport, move the
    // layout viewport such that it remains inside the visual viewport. Otherwise,
    // move the layout viewport such that the visual viewport is contained
    // inside the layout viewport.
```
  * To determine which of these is the case, we test whether the visual viewport is smaller than the layout viewport in both dimensions. **Due to the rounding error mentioned above, the check for the vertical dimension fails.** We do have a `FuzzyEqualsMultiplicative` check, but the difference here is too large for it.
  * Therefore, we attempt to do the second thing, "move the layout viewport such that the visual viewport is contained inside it", which results in **increasing the layout viewport offset to 100 as well**.
  * [Layout grumbles about APZ moving the layout viewport in an `overflow: hidden` dimension, but accepts in nonetheless.](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/apz/util/APZCCallbackHelper.cpp#124)
  * When layout recomputes the APZ scrollable rect, [its origin is the new layout viewport offset](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/layout/base/nsLayoutUtils.cpp#8450), which is now 100 horizontally.
  * As far as APZ is concerned, the allowable scrollable range for the page is now (100,0,1440,1790.15), rather than (0,0,1440,1790.15). That is, 100 on the left side of the page just became inaccessible.
  * If you're still at this zoom level, you can scroll back there via the same process, but if you zoom in, the visual viewport is now properly contained inside the layout viewport, so the ability to sneakily async-scroll the layout viewport out of bounds is lost, and the [0,100] range is truly inaccessible until you zoom back out.

Here's what's happening on this page:

  * The page has a content size of (1980.03, 1790.15) CSS pixels, and a layout viewport size of (1440, 1790.15). The page is `overflow-x: hidden`, so the layout viewport cannot be horizontally scrolled via user input.
  * When zoomed out as far as possible, the zoom level is ~0.858. The composition bounds on my phone is (1080, 1536) screen pixels, leading to a visual viewport size of (1258.74, 1790.21) CSS pixels. **Observe how this is a fraction of a pixel taller than the layout viewport due to rounding error.**
  * The visual viewport is legitimately horizontally scrollable within the layout viewport. When the user scrolls it to the right, the horizontal visual viewport offset increases from 0 to some larger value, say 100.
  * We then run the logic in `KeepLayoutViewportEnclosingVisualViewport`, which is described as follows:
```
    // If visual viewport size is greater than the layout viewport, move the
    // layout viewport such that it remains inside the visual viewport. Otherwise,
    // move the layout viewport such that the visual viewport is contained
    // inside the layout viewport.
```
  * To determine which of these is the case, we test whether the visual viewport is smaller than the layout viewport in both dimensions. **Due to the rounding error mentioned above, the check for the vertical dimension fails.** We do have a `FuzzyEqualsMultiplicative` check, but the difference here is too large for it.
  * Therefore, we attempt to do the second thing, "move the layout viewport such that the visual viewport is contained inside it", which results in **increasing the layout viewport offset to 100 as well**.
  * [Layout grumbles about APZ moving the layout viewport in an `overflow: hidden` dimension, but accepts in nonetheless.](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/apz/util/APZCCallbackHelper.cpp#124)
  * When layout recomputes the APZ scrollable rect, [its origin is the new layout viewport offset](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/layout/base/nsLayoutUtils.cpp#8450), which is now 100 horizontally.
  * As far as APZ is concerned, the allowable scrollable range for the page is now (100,0,1440,1790.15), rather than (0,0,1440,1790.15). That is, 100 pixels on the left side of the page just became inaccessible.
  * If you're still at this zoom level, you can scroll back there via the same process, but if you zoom in, the visual viewport is now properly contained inside the layout viewport, so the ability to sneakily async-scroll the layout viewport out of bounds is lost, and the [0,100] range is truly inaccessible until you zoom back out.

Here's what's happening on this page:

  * The page has a content size of (1980.03, 1790.15) CSS pixels, and a layout viewport size of (1440, 1790.15). The page is `overflow-x: hidden`, so the layout viewport cannot be horizontally scrolled via user input.
  * When zoomed out as far as possible, the zoom level is ~0.858. The composition bounds on my phone is (1080, 1536) screen pixels, leading to a visual viewport size of (1258.74, 1790.21) CSS pixels. **Observe how this is a fraction of a pixel taller than the layout viewport due to rounding error.**
  * The visual viewport is legitimately horizontally scrollable within the layout viewport. When the user scrolls it to the right, the horizontal visual viewport offset increases from 0 to some larger value, say 100.
  * We then run the logic in `KeepLayoutViewportEnclosingVisualViewport`, which is [described as follows](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/FrameMetrics.cpp#40):
```
    // If visual viewport size is greater than the layout viewport, move the
    // layout viewport such that it remains inside the visual viewport. Otherwise,
    // move the layout viewport such that the visual viewport is contained
    // inside the layout viewport.
```
  * To determine which of these is the case, we test whether the visual viewport is smaller than the layout viewport in both dimensions. **Due to the rounding error mentioned above, the check for the vertical dimension fails.** We do have a `FuzzyEqualsMultiplicative` check, but the difference here is too large for it.
  * Therefore, we attempt to do the second thing, "move the layout viewport such that the visual viewport is contained inside it", which results in **increasing the layout viewport offset to 100 as well**.
  * [Layout grumbles about APZ moving the layout viewport in an `overflow: hidden` dimension, but accepts in nonetheless.](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/apz/util/APZCCallbackHelper.cpp#124)
  * When layout recomputes the APZ scrollable rect, [its origin is the new layout viewport offset](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/layout/base/nsLayoutUtils.cpp#8450), which is now 100 horizontally.
  * As far as APZ is concerned, the allowable scrollable range for the page is now (100,0,1440,1790.15), rather than (0,0,1440,1790.15). That is, 100 pixels on the left side of the page just became inaccessible.
  * If you're still at this zoom level, you can scroll back there via the same process, but if you zoom in, the visual viewport is now properly contained inside the layout viewport, so the ability to sneakily async-scroll the layout viewport out of bounds is lost, and the [0,100] range is truly inaccessible until you zoom back out.

Here's what's happening on this page:

  * The page has a content size of (1980.03, 1790.15) CSS pixels, and a layout viewport size of (1440, 1790.15). The page is `overflow-x: hidden`, so the layout viewport cannot be horizontally scrolled via user input.
  * When zoomed out as far as possible, the zoom level is ~0.858. The composition bounds on my phone is (1080, 1536) screen pixels, leading to a visual viewport size of (1258.74, 1790.21) CSS pixels. **Observe how this is a fraction of a pixel taller than the layout viewport due to rounding error.**
  * The visual viewport is legitimately horizontally scrollable within the layout viewport. When the user scrolls it to the right, the horizontal visual viewport offset increases from 0 to some larger value, say 100.
  * We then run the logic in `KeepLayoutViewportEnclosingVisualViewport`, which is [described as follows](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/FrameMetrics.cpp#40):
```
    // If visual viewport size is greater than the layout viewport, move the
    // layout viewport such that it remains inside the visual viewport. Otherwise,
    // move the layout viewport such that the visual viewport is contained
    // inside the layout viewport.
```
  * To determine which of these is the case, we test whether the visual viewport is smaller than the layout viewport in both dimensions. **Due to the rounding error mentioned above, the check for the vertical dimension fails.** We [do have a `FuzzyEqualsMultiplicative` check](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/FrameMetrics.cpp#45), but the difference here is too large for it.
  * Therefore, we attempt to do the second thing, "move the layout viewport such that the visual viewport is contained inside it", which results in **increasing the layout viewport offset to 100 as well**.
  * [Layout grumbles about APZ moving the layout viewport in an `overflow: hidden` dimension, but accepts in nonetheless.](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/gfx/layers/apz/util/APZCCallbackHelper.cpp#124)
  * When layout recomputes the APZ scrollable rect, [its origin is the new layout viewport offset](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/layout/base/nsLayoutUtils.cpp#8450), which is now 100 horizontally.
  * As far as APZ is concerned, the allowable scrollable range for the page is now (100,0,1440,1790.15), rather than (0,0,1440,1790.15). That is, 100 pixels on the left side of the page just became inaccessible.
  * If you're still at this zoom level, you can scroll back there via the same process, but if you zoom in, the visual viewport is now properly contained inside the layout viewport, so the ability to sneakily async-scroll the layout viewport out of bounds is lost, and the [0,100] range is truly inaccessible until you zoom back out.