STR

1. Run latest nightly with apz.allow_zooming=true
2. Load https://bugzilla.mozilla.org/show_bug.cgi?id=1556556
3. Pinch-zoom in. Observe that a horizontal viewport scrollbar appears.
4. Try to drag the horizontal viewport scrollbar.

Expected results

The horizontal viewport scrollbar can be dragged

Actual results

The horizontal viewport scrollbar remains at its initial position and cannot be used to scroll the viewport. If it starts away from its initial position, attempting to drag it causes it to jump to its initial position.

Lots of problems visible using those STR (testing on mac). The vertical scroll bar is sometimes visible, sometimes not. The header sometimes stays on screen, sometimes does not.

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

The vertical scroll bar is sometimes visible, sometimes not. The header sometimes stays on screen, sometimes does not.

Assuming you mean the subframe's vertical scrollbar, that's expected. The subframe's viewport is sized to the page's layout viewport, and so whether the subframe's vertical scrollbar is visible depends on where the visual viewport is positioned within the layout viewport.

The same goes for the header, which is also sized and positioned relative to the layout viewport.

This appears to have been broken for quite a while, and it's basically any page that doesn't have horizontal overflow before zooming that is affected.

Layout hittesting (nsLayoutUtils::GetFrameForArea) when it happens seems to hit the right element.

So it looks like we are getting into the scrollbar dragging code on the apzc side, but it calculate a very small "percent", dragging the scrollbar across the whole window I move from ~0% to ~1.1%.

Nevermind, 1.1 was not 1.1% but is actually 110% (the calculation allows us to go over 100% by quite a bit for some reason).

The problem is in AsyncPanZoomController::HandleDragEvent we compare GetScrollableRect to CalculateCompositionBoundsInCssPixelsOfSurroundingContent to determine how much we can scroll, in a "zoomed overflow hidden" situation those are the same.

I think we'll need an equivalent calculation to this

https://bugzilla.mozilla.org/show_bug.cgi?id=1601185#c6

The scroll position and scrollable rect are inside the zoom boundary so we need to use the composisted size inside the zoom boundary as well.

There's still at least two more issues with interacting with the scroll bar after this patch, but dragging seems to work fine. I'll file those as new bugs.

One of the issues is bug 1639448.

The other one is bug 1639450.

https://hg.mozilla.org/mozilla-central/rev/6191dcf6f130