1478690 - Displayport should be positioned relative to the visual viewport offset

Status: RESOLVED DUPLICATE of bug 1664101

(Core :: Panning and Zooming, enhancement, P3)

Description

[Tanushree Podder [:tanushree]]

Following the changes in bug 1423011 (Allow APZ to aync-scroll the layout viewport), the displayport is positioned relative to the layout viewport offset for the root content document's root scroll frame (RCD-RSF). However, the displayport should be positioned relative to the visual viewport offset. The changes in bug 1423011 apply an adjustment to the displayport margins in APZ to temporarily fix this. 

Using the visual viewport offset stored in the presshell, the displayport can be positioned relative to the visual viewport for the RCD-RSF by the main thread. Therefore, the adjustment to the displayport margins in APZ will not be required for the RCD-RSF.

Comment 1

[Tanushree Podder [:tanushree]]

Attachment: Displayport positioning partial fix

The attached patch has the changes to layout and APZ which are required to position the displayport according to the visual viewport offset for the RCD-RSF. The patch also contains commented logging statements used to debug the problem. After applying the changes in the patch, the displayport is still getting positioned according to the layout viewport offset. 

In particular, it was observed that whenever the offset for the |expandedScrollableRect| is less than 0 in https://searchfox.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#962, the displayport offset is computed correctly in layout but the final displayport offset observed in the minimap is (0,0).

To resolve this issue, we will have to investigate further into what causes the displayport to get positioned incorrectly after GetDisplayPortFromMarginsData is called in layout.

Comment 2

[Botond Ballo [:botond]]

I was "mentoring" this while Tanushree was working on it, but I don't think it's a good mentored bug for a casual contributor.

Comment 3

[Botond Ballo [:botond]]

Based on my investigation in bug 1664101, I suspect that at least one of the reasons why the patch in this bug caused regressions, is that it did not update all codepaths where we performed the "adjustment" described in comment 0. (Though it's hard to be sure without having a search-indexed version of the code as it stood in 2018.)

In any case, bug 1664101 will effectively accomplish the original goal of this bug, so I'm going to close this as a dupe.