Bugzilla

(In reply to Botond Ballo [:botond] from comment #0)
> 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.

This reflects the fact that the subframe is inside fixed content which is not subject to the root content APZC's scroll transform.

However, this code has not been updated to properly reflect the changes made when we made fixed content be fixed to the layout viewport, thereby making it subject to the part of the root content APZC's async transform which reflects the offset of the visual viewport inside the layout viewport.

Note, when an event targets a part of fixed content that is not inside a subframe, the APZC coordinates are correct, because the target APZC is now the root content APZC. I believe this happens because the initial target APZC is determined by the scroll id returned by the WebRender hit test, and this how we assign scroll ids to hit-test-info items during display list building [here](https://searchfox.org/mozilla-central/rev/2f5ed7b7244172d46f538051250b14fb4d8f1a5f/layout/painting/HitTestInfo.cpp#35-43): if we're inside any sort of scrolled content, we assign the scroll frame's scroll id, otherwise if we're inside fixed content, we assign the scroll id of the scroll frame we are fixed to. An APZC's parent, however, is determined by the structure of the WebRenderScrollData, and there, nodes representing fixed content are deliberately outside of the node with the root content APZC's metadata.

It's not immediately clear to me how best to fix this. I suspect it's likely to require some refactoring.

(In reply to Botond Ballo [:botond] from comment #0)
> 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.

This reflects the fact that the subframe is inside fixed content which is not subject to the root content APZC's scroll transform.

However, this code has not been updated to properly reflect the changes made when we made fixed content be fixed to the layout viewport, thereby making it subject to the part of the root content APZC's async transform which reflects the offset of the visual viewport inside the layout viewport.

Note, when an event targets a part of fixed content that is not inside a subframe, the APZC coordinates are correct, because the target APZC is now the root content APZC. I believe this happens because the initial target APZC is determined by the scroll id returned by the WebRender hit test, and this is how we assign scroll ids to hit-test-info items during display list building [here](https://searchfox.org/mozilla-central/rev/2f5ed7b7244172d46f538051250b14fb4d8f1a5f/layout/painting/HitTestInfo.cpp#35-43): if we're inside any sort of scrolled content, we assign the scroll frame's scroll id, otherwise if we're inside fixed content, we assign the scroll id of the scroll frame we are fixed to. An APZC's parent, however, is determined by the structure of the WebRenderScrollData, and there, nodes representing fixed content are deliberately outside of the node with the root content APZC's metadata.

It's not immediately clear to me how best to fix this. I suspect it's likely to require some refactoring.