From bug 1509575 comment 12:

(In reply to Jan Henning [:JanH] from comment #12)

One more thing, though - right now I just commented out the code in Fennec
that was resetting isFirstPaint and while this does break the UI rather
severely because we're never clearing the clear colour we're drawing front
of the content until we've painted something, I can still reproduce this
problem.
Through getting my test case to work I've confirmed that resetting the
isFirstPaint flag on the chrome window (at least in Fennec - I still need to
get the test working on Desktop with e10s) does indeed get APZ into the code
path where it overwrites its own scroll position with the scroll position
from the incoming FrameMetrics, which courtesy of ComputeScrollMetadata
contains the layout viewport position.

However it seems that switching tabs or getting a page from the bfcache is
sufficient to trigger the same issue even when aIsFirstPaint is false. So
while my patch would be sufficient for Fennec (which one way or another
apparently is resetting isFirstPaint for all the relevant cases), it doesn't
yet cover all potential cases.

This bug tracks investigating this case.

Defaulting this to P3 since it sounds like a not-too-severe issue. Feel free to adjust to P2 or P1 if I'm mistaken.

I think GeckoView doesn't play around with the isFirstPaint flag, so they would probably be affected?

I expect this was fixed by bug 1627012.