This is a little puzzling to me. In a process with a single scrollframe, mScrollGeneration is always equal to sScrollGenerationCounter, because mScrollGeneration is only ever assigned to by statements of the form mScrollGeneration = ++sScrollGenerationCounter. So we can say that mScrollGeneration != sScrollGenerationCounter if and only if there is another scrollframe in the process, and that scrollframe got a new scroll request. And that's precisely the case that we want to ignore in this bug, which means we should be able to accomplish it by simply removing that clause from the if condition. The fact that mApzSmoothScrollDestination gets reset to Nothing() via other scroll methods should be sufficient to guarantee correctness.

Not a strict blocker, but getting rid of the use site of sScrollGenerationCounter makes things cleaner.

I verified my intuition in comment 1 with tests and a patch. https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=aed298abe93fbfbef226e9a5fd2ec31f37eacc23

Retro-test to ensure we don't regress the scenario from bug 1228407.

In the case where there are two scrollframes that get scrolled in an
interleaved manner, the scroll generation counter continually advances
and blocks APZ from updating the main-thread scroll position. This
fixes that by removing the scroll generation counter check from the
relevant condition. The clause is entirely redundant when there is only
a single scrollframe and only causes problems when there are multiple
scrollframes.

Depends on D97033

https://hg.mozilla.org/mozilla-central/rev/05c9cf63ecb0
https://hg.mozilla.org/mozilla-central/rev/f970b5bdfdbe