Closed Bug 1262182 Opened 4 years ago Closed 4 years ago
Bad checkerboarding when flinging to the top of the page when large subframes are present
+++ This bug was initially created as a clone of Bug #1251638 +++ STR: 1. Load https://github.com/mozilla/gecko-dev/blob/master/layout/base/FrameLayerBuilder.cpp 2. Scroll the code horizontally, to trigger the creation of a displayport on the horizontally scrollable subframe. 3. Before the subframe displayport expires, scroll down and then scroll quickly back up to the top of the page. Expected results: The page checkerboards as little as when you haven't scrolled the subframe. Actual results: The subframe checkerboards for a few seconds before filling in. I believe this happens because as the user scrolls up, the displayport base rect for the subframe only shifts when the top-level frame gets repainted. This only happens on a (virtual) tile rollover, and doesn't happen at all once the displayport hits the top of the page. You can see this if you enable the APZ minimap - once the green rect hits the top, no more repaints occur. If, at this point, the subframe's base rect is really far down, it can get left there and result in checkerboarding in the top of the visible part of the subframe. This is really a perma-checkerboard that goes away on the next paint, which is triggered by unrelated code. I'm not sure what a good fix here is, short of triggering more repaints (i.e. undoing the optimization that bug 1192910 added. I thought my patch in bug 1259593 would avoid the problem but it makes things worse in general so I backed it out. Perhaps an alternative would be to detect this scenario somehow and schedule a paint explicitly if we run into it.
I can still repro this on 48, but I don't see it on 49 Aurora or 50 Nightly. Not sure what fixed it, but I'll close it as WFM. We can reopen it if it comes back.
You need to log in before you can comment on or make changes to this bug.