User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Build ID: 20200914095101

Steps to reproduce

1. Open this Wikipedia link 5 times in background tabs.
2. Switch to those tabs.
3. Scroll up and down.

Actual result

(Please refer to the attached videos.)

1. In some tabs the content is not rendered after scrolling.
2. For those tabs, the click position is wrong after scrolling. (This feels like bug 1662379 but I haven't encountered it before bug 1662013 is fixed.)
3. After switch away and back to the tab, the content position is wrong.

Notes

1. I cannot reproduce all the issues if I open the Wiki link in the current tab.
2. The wrong click position issue is very easy to encounter. In YouTube, for example, scroll a little bit then click the video controls. Most of the time it misses.
3. This does not always occur on all background tabs.
4. Issues can be reproduced in a new profile.

System info

Windows 10 1909
Nvidia GTX 760. Driver v451.67.

About:support for my system.

From Mozregression:

Last good Nightly: 2020-09-11
First bad Nighlty: 2020-09-12
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=941862090875537f3cbadc0fbbae6e77535fcc26&tochange=48f10c4139655c2c4d52fa773f1fd760ea681d42

Bisecting autoland builds:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ab8e3128766e0ddf03d71783f2cb61297aef1bbb&tochange=04b1220fb04324826c66621cd90896c363bc0009

This is regressed by bug 1662013. (Bug 1661903 fixes a test only.)

I'm seeing this too fwiw. Thanks for the bisection and the STR Fanolian!

I've also seen it in Phabricator, fwiw.

I'll take a look, thanks.

So the problem here is that we end up in a state where APZ has the wrong scroll generation. This results in the repaint request always failing to run this code and then APZCCallbackHelper::IsScrollInProgress() always returns true even when it shouldn't. This causes the APZ scroll change to not get applied to the main thread, getting things out of sync.

The APZ scroll generation is wrong because sometimes we get into NotifyLayersUpdated and take the isDefault branch here but there are no scroll position updates in the metadata. This ends up incorrectly preserving the "0" scroll generation on the metrics instead of adopting the updated generation from the incoming metrics.

I have a simple fix that I'd like to land quickly since this probably affects a lot of people. I can work on writing a test after. And I'll try to improve the code structure in bug 1662019 once the test is in place, to ensure this doesn't regress again.

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=f799351ca3aa603fcb7b69ed89004497504892f7

I investigated this more with rr to get a better understanding of the exact mechanism that causes this scenario. Turns out that the main thread does a paint of the content, but before the parent process has updated the RefLayer to point to the new tab. So main thread paint (which has firstPaint=true and the ScrollPositionUpdate instances on the metadata) gets sent to the compositor, but APZ's UpdateHitTestingTree function doesn't actually walk into the layer subtree for that content process (because the RefLayer is still pointing to the old tab's content layer tree). Thus the paint is "dropped" from the APZ point of view, and then after the tab switch is complete the APZC instance gets created and gets a metadata from a new paint. This metadata doesn't have the ScrollPositionUpdates any more, but just has the latest generation number.

Try push for the test: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=ee7c844b6a050c0b6e65646953f46099ffebf11c

https://hg.mozilla.org/mozilla-central/rev/ba172dcd1f2f
https://hg.mozilla.org/mozilla-central/rev/7f3f056d1898