1569599 - Main thread scroll offset not updated if there are relative updates every frame

Status: NEW

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

Description

[Emilio Cobos Álvarez (:emilio)]

Test-case: attachment 9080615 [details].

This is the root cause of bug 1568778 (the relative updates are done via scroll anchoring).

We fixed scroll anchoring so as to not loop indefinitely in that case, but seems like this should be fixed anyhow.

Per bug 1568778 comment 7, this is not straight-forward and probably worth a different bug.

Comment 1

[Botond Ballo [:botond]]

I guess what we need here is sort of a relative update in the reverse direction (from APZ to the main thread).

Our current relative updates work by taking the current main thread scroll offset, subtracting from it a "base" scroll offset to produce a delta, and applying it to the APZ scroll offset.

Here, we'd want to take the current APZ scroll offset, subtract from it a "base" APZ scroll offset to produce a delta, and apply it to the main thread scroll offset.

I think we'd want to do it around here. In the case where IsScrollInProgress() returns true because a relative update is pending (i.e. because aFrame->LastScrollOrigin() == nsGkAtoms::relative), we would:

• Take the current APZ scroll offset (targetScrollPosition)
• Subtract the base APZ scroll offset, which would be aFrame->GetApzScrollPosition(), to get the delta
• Add that delta to the current main thread scroll position (aFrame->GetScrollPosition()) and scroll there, taking care to preserve the last scroll origin as nsGkAtoms::relative
• We'll want to add the delta to the base as well (i.e. aFrame->mApzScrollPos += delta) so that the pending relative update remains meaningful

The exact implementation approach remains to be nailed down; for example, we could try to do the above by calling ScrollToCSSPixelsApproximate() with a special flag (perhaps a new nsGkAtoms::apzRelative origin), or call a new purpose-written function that does the above more specifically.

Comment 2

[Botond Ballo [:botond]]

I wonder if this was fixed by bug 1695598.

Comment 3

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #2)

I wonder if this was fixed by bug 1695598.

Looks like not.

Comment 4

[Botond Ballo [:botond]]

Recording a note from an earlier discussion of this bug: we should check whether "pure relative" updates are affected in the same way. If so, the bug is likely to be more noticeable.