1262182 - Bad checkerboarding when flinging to the top of the page when large subframes are present

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

+++ 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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

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.