Bugzilla

**STR**

 1. Run Firefox on a desktop machine with a touchpad or touchscreen (or, barring that, with the pref `mousewheel.with_alt.action=5` set to allow simulating pinch-zooming via alt+mousewheel). 
     * While not required to reproduce, on Linux I find it helpful to set `widget.gtk.overlay-scrollbars.enabled=false` as well.
 2. Pinch-zoom in. The bug is more readily noticeable at larger zooms (e.g. 2x rather than 1.2x).
 3. Scroll the root scroll frame down a bit. Since the page is pinch-zoomed in, this scrolls the visual viewport inside the layout viewport, so the fixed (blue) element should start to move offscreen, and the subframe inside it should move closer to the top of the viewport.
  4. Try to drag the (vertical) scrollbar of the subframe.

**Expected results**

Scrollbar dragging works.

**Actual results**

Dragging the scrollbar initially has no effect. Eventually, after you've moved the mouse a ways down, it starts moving and tracking the mouse (but its position remains offset by the initial distance for which it was non-responsive).

**Diagnosis**

APZ scrollbar dragging is one of the few remaining places where the numerical value of input events' APZC coordinates (i.e. the coordinates after applying `GetScreenToApzcTransform` but before applying `GetApzcToGeckoTransform`) is important for correctness.

In this situation (APZC for a subframe inside fixed content, and there is an offset between the visual and layout viewports), the APZC coordinates are incorrect. The target APZC is the subframe (as expected), but this APZC's parent chain does not include the root content APZC, whose async transform contains the offset between the visual and layout viewports. Rather, the target APZC's `GetParent()` is the enclosing (chrome document) APZC.

As a result, the target APZC's `GetScreenToApzcTransform()` does not include this offset. But visually, translation by this offset **does** apply to the fixed content and its descendants, including the subframe.

The offset is similarly missing from `GetApzcToGeckoTransform()`, which makes the Gecko coordinates work out to be correct (and thus e.g. buttons on the fixed content can still be clicked correctly).

**STR**

 1. Run Firefox on a desktop machine with a touchpad or touchscreen (or, barring that, with the pref `mousewheel.with_alt.action=5` set to allow simulating pinch-zooming via alt+mousewheel). 
     * While not required to reproduce, on Linux I find it helpful to set `widget.gtk.overlay-scrollbars.enabled=false` as well.
 2. Pinch-zoom in. The bug is more readily noticeable at larger zooms (e.g. 2x rather than 1.2x).
 3. Scroll the root scroll frame down a bit. Since the page is pinch-zoomed in, this (initially) scrolls the visual viewport inside the layout viewport, so the fixed (blue) element should start to move offscreen, and the subframe inside it should move closer to the top of the viewport.
  4. Try to drag the (vertical) scrollbar of the subframe.

**Expected results**

Scrollbar dragging works.

**Actual results**

Dragging the scrollbar initially has no effect. Eventually, after you've moved the mouse a ways down, it starts moving and tracking the mouse (but its position remains offset by the initial distance for which it was non-responsive).

**Diagnosis**

APZ scrollbar dragging is one of the few remaining places where the numerical value of input events' APZC coordinates (i.e. the coordinates after applying `GetScreenToApzcTransform` but before applying `GetApzcToGeckoTransform`) is important for correctness.

In this situation (APZC for a subframe inside fixed content, and there is an offset between the visual and layout viewports), the APZC coordinates are incorrect. The target APZC is the subframe (as expected), but this APZC's parent chain does not include the root content APZC, whose async transform contains the offset between the visual and layout viewports. Rather, the target APZC's `GetParent()` is the enclosing (chrome document) APZC.

As a result, the target APZC's `GetScreenToApzcTransform()` does not include this offset. But visually, translation by this offset **does** apply to the fixed content and its descendants, including the subframe.

The offset is similarly missing from `GetApzcToGeckoTransform()`, which makes the Gecko coordinates work out to be correct (and thus e.g. buttons on the fixed content can still be clicked correctly).

**STR**

 1. Run Firefox on a desktop machine with a touchpad or touchscreen (or, barring that, with the pref `mousewheel.with_alt.action=5` set to allow simulating pinch-zooming via alt+mousewheel). 
     * While not required to reproduce, on Linux I find it helpful to set `widget.gtk.overlay-scrollbars.enabled=false` as well.
 2. Pinch-zoom in. The bug is more readily noticeable at larger zooms (e.g. 2x rather than 1.2x).
 3. Scroll the root scroll frame down a bit. Since the page is pinch-zoomed in, this (initially) scrolls the visual viewport inside the layout viewport, so the fixed (blue) element should start to move offscreen, and the subframe inside it should move closer to the top of the viewport. Scroll until the top of the subframe is close to the top of the viewport.
  4. Try to drag the (vertical) scrollbar of the subframe.

**Expected results**

Scrollbar dragging works.

**Actual results**

Dragging the scrollbar initially has no effect. Eventually, after you've moved the mouse a ways down, it starts moving and tracking the mouse (but its position remains offset by the initial distance for which it was non-responsive).

**Diagnosis**

APZ scrollbar dragging is one of the few remaining places where the numerical value of input events' APZC coordinates (i.e. the coordinates after applying `GetScreenToApzcTransform` but before applying `GetApzcToGeckoTransform`) is important for correctness.

In this situation (APZC for a subframe inside fixed content, and there is an offset between the visual and layout viewports), the APZC coordinates are incorrect. The target APZC is the subframe (as expected), but this APZC's parent chain does not include the root content APZC, whose async transform contains the offset between the visual and layout viewports. Rather, the target APZC's `GetParent()` is the enclosing (chrome document) APZC.

As a result, the target APZC's `GetScreenToApzcTransform()` does not include this offset. But visually, translation by this offset **does** apply to the fixed content and its descendants, including the subframe.

The offset is similarly missing from `GetApzcToGeckoTransform()`, which makes the Gecko coordinates work out to be correct (and thus e.g. buttons on the fixed content can still be clicked correctly).