Bug 6278 – REGRESSION: Incomplete repaint when table cell width changes during layout

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Rosyna]

I'm getting significant relayout glitches on some webpages. At first I thought this was related to bug 5699 
but I still get it (mostly at cnn.com) even when running ToT. It *seems* to be related to an image loading 
after a the page is first laid out, but one that changes the size of the surrounding area (such as one with 
no size being loaded and forcing a relayout). You can see what it produces at http://www.unsanity.org/
rosyna/imgs/repaint.png which I do not believe is the correct rendering (but I could very well be wrong).

I also get this at http://blogs.msdn.com/ericgu/archive/2005/12/28/507854.aspx in which a piece of the 
blue stripe at the bottom appears about 40px above the stripe on the bottom.

[Eric Seidel (no email)]

Sounds a little like :http://bugzilla.opendarwin.org/show_bug.cgi?id=6276

[Rosyna]

Does not look to be, as this error I am seeing gets "corrected" if I do a select all (which forces a repaint). 
The image one doesn't look like that would be fixed that way. And this seems to never happen with 
images. Plus, this error is always vertical in nature from my experience, never a horizontal or "splitting" 
error.

[Geoffrey Garen]

I see this @ http://www.cnn.com/2005/HEALTH/diet.fitness/12/28/winter.activekids.ap/index.html (pic 
attached).

When the medpagetoday graphic loads, it smushes the "Fitness experts..." title, causing the title to re-
layout and break into two lines. This pushes all the text below it down, but it looks like the original text 
doesn't get deleted before the new text draws.

[Geoffrey Garen]

Created attachment 5346 [details]
Fitness Experts pic

[David Kilzer (:ddkilzer)]

This is a duplicate of Bug 3509.  I can't seem to reproduce the glitches on unsanity.org or the MSDN blog 
today, but the CNN link in Comment 3 behaves exactly like Bug 3509.

You may "fix" the rendering by doing a "Select All" operation on the web page, or by hiding Safari then 
switching back to it.


*** This bug has been marked as a duplicate of 3509 ***

My fix for bug 3509 (which I am going to post soon) doesn't fix this bug (nor the remaining issue with the page from bug 6276), so I'm re-separating it.

Created attachment 5808 [details]
Reduction

P1 since it's a regression.

In the reduced testcase, the left cell doesn't get invalidated before layout, since it is not marked as needing layout at that point (only the right cell is). If you initiate the change on the left cell (e.g. by doing document.getElementById('col1').style.width='500px'), then the left cell is marked as needing layout early on and therefore gets repainted before layout, and you don't get the buggy behavior.

I have an ugly fix for this specific case but I think the problem may be more general (whenever an object gets marked as needing layout during relayout and its parent wasn't marked as needing layout for itself before), so I'm still trying to figure out a general solution.

Created attachment 5949 [details]
Make the cell repaintObjectsBeforeLayout

[Darin Adler]

Comment on attachment 5949 [details]
Make the cell repaintObjectsBeforeLayout

I studied the checkForRepaintDuringLayout function and how it's called, and as far as I can see, this looks good. r=me

[Alexey Proskuryakov]

Landed, r12390.

[Alexey Proskuryakov]

BuildBot says three tests started to fail with this checkin:
http://build.webkit.org/post-commit-powerpc-mac-os-x/builds/328/step-layout-test/0

Which is rather strange, because I did run layout tests before landing the patch.

[Alexey Proskuryakov]

False alarm - either the next update or a clean rebuild (I did both) has resolved this.

[Eric Seidel (no email)]

Removing Regression keyword from bugs already fixed.