Bug 1627012 - Update the APZC scroll offset to the main thread's visual scroll offset for new APZCs. r=botond

This is the main fix for the bug. When APZ is getting metrics from the main
thread "for the first time" it should accept the visual scroll offset in the
main thread metrics. Normally one would expect the isFirstPaint flag to be
set on this call to NotifyLayersUpdated, but that seems to only ever be set
on the very first paint of a presShell. In particular it is not set after a
tabswitch because the brower's async tab switching mechanism means that the
layer tree is already cached in the compositor.

Differential Revision: https://phabricator.services.mozilla.com/D76812
This commit is contained in:
Kartikaya Gupta 2020-05-28 01:56:43 +00:00
parent 8183fac5b1
commit f6138147f4

View File

@ -4503,6 +4503,9 @@ void AsyncPanZoomController::NotifyLayersUpdated(
aLayerMetrics.GetDoSmoothScroll() &&
(aLayerMetrics.GetScrollGeneration() != Metrics().GetScrollGeneration());
// If `isDefault` is true, this APZC is a "new" one (this is the first time
// it's getting a NotifyLayersUpdated call). In this case we want to apply the
// visual scroll offset from the main thread to our scroll offset.
// The main thread may also ask us to scroll the visual viewport to a
// particular location. This is different from a layout viewport offset update
// in that the layout viewport offset is limited to the layout scroll range
@ -4514,6 +4517,7 @@ void AsyncPanZoomController::NotifyLayersUpdated(
// to scroll both the layout and visual viewports to distinct (but compatible)
// locations (via e.g. both updates being eRestore).
bool visualScrollOffsetUpdated =
isDefault ||
aLayerMetrics.GetVisualScrollUpdateType() != FrameMetrics::eNone;
if ((aLayerMetrics.GetScrollUpdateType() == FrameMetrics::eMainThread &&
aLayerMetrics.GetVisualScrollUpdateType() !=