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.
Sounds a little like :http://bugzilla.opendarwin.org/show_bug.cgi?id=6276
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.
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.
Created attachment 5346 [details] Fitness Experts pic
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
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
Landed, r12390.
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.
False alarm - either the next update or a clean rebuild (I did both) has resolved this.
Removing Regression keyword from bugs already fixed.