Under a certain network or server speed, the directory table in the URL is laid out and painted twice, with the first layout being taller than the final layout. The area that doesn't belong to the final layout isn't repainted with the backgroun (see attachment).
Created attachment 10176 [details] Screenshot
Created attachment 10179 [details] Reduction
Bug 11205 is possibly a duplicate.
This is essentially the same problem as bug 3509, but in this case the out-of-place repaints include "before layout" painting, so the extra painting added to fix bug 3509 don't help. Tables cheat and do one last "before layout" paint in RenderTableSection::setCellWidths() if cell widths change (needed to fix bug 6278), and that's what you're missing here.
So, based on the above statement, will this be fixed anytime soon?
Created attachment 12581 [details] Reduction without tables This is not specific to tables.
Radar <rdar://problem/4959697>
Created attachment 12728 [details] [WIP] Let objects know how far off they are from where their last layout took place Work in progress. I think I can refine it so that I could remove some of the current "compensate for intermediate layout/repaint at the wrong coords" code.
Created attachment 12730 [details] Let objects know how far off they are from where their last layout took place Added change log and repaint test. > I think I can refine it so that I could remove some of the > current "compensate for intermediate layout/repaint at the wrong > coords" code. I decided not to do it now (because it's too hard). This means that there might still be some excessive painting, however none of it was added by this patch. This patch merely moves some of the current painting to the right place.
Comment on attachment 12730 [details] Let objects know how far off they are from where their last layout took place Looks good to me, but I want to hear Hyatt's take on this one.
Comment on attachment 12730 [details] Let objects know how far off they are from where their last layout took place r=me
Landed in r19492.
*** Bug 11205 has been marked as a duplicate of this bug. ***