266 bytes, patch
|Details | Diff | Splinter Review|
When loading a new page, there is a time after location change when the old content has been retained and new content will not paint. Widget invalidations will cause a repaint, but displayport updates of course do not count as widget invalidations. The result? If the user is loading a new page and is still scrolling around the old one, she will see checkerboard for a while until the initial reflow occurs and the paint suppression timer is done. When the user begins to see checkerboard (or begins to scroll at all?), we could immediately invalidate the widget so that a nice background is painted so that checkerboard is not just sitting there, waiting for a page load. I don't know if nsIDOMWindowUtils::Redraw will cause a widget invalidation, but it's a good candidate to try.
Created attachment 555791 [details] [diff] [review] WIP: on any panning before first paint, force a widget update
This sort of does the job, but I think the first widget invalidate triggers the first paint, meaning even though no frame is ready to be painted, you can scroll around as if the page had painted. So, if we start basing scrolling on contentWidth and contentHeight in MainDragger instead of MozScrolledAreaChanged, then that would probably tell us exactly what we're working with in the parent process: a simple white background or actual content.