Visit the sample URL, and click in the entry box to focus it. As the cursor flashes, repaints are issued. However, because the entry box is within a frameset, the repaint is applied to the full contents of the frameset rather than just the entry box. (You can check this by adding a printf() in WebFrame::paint() to print out ps.rcPaint. Compare that to what happens when you just navigate to the frame with the entry box - http://stein.cshl.org/WWW/CGI/examples/frameset.cgi/query). This happens because on every call to FrameView::layout, the following code is executed: if (body->hasTagName(framesetTag)) { body->renderer()->setNeedsLayout(true); This seems unnecessary and wrong. I believe the correct fix is to remove the call to setNeedsLayout. I'll make sure that doesn't break the layout tests, and submit a patch.
Layout is only done if needed. You're looking at buggy Windows code. Repaints do not trigger a relayout normally, but the buggy windows code always calls layout over and over when painting (even when no layout is necesary). This will lead to many strange bugs. That said, I do agree that setNeedsLayout here is wrong. It should be setChildNeedsLayout just like the body tag code path.
Created attachment 11941 [details] only call setNeedsLayout(true) if the view's size has changed
Sorry Dave, I didn't see your comment until now. Do you mean to simply replace the call to setNeedsLayout() with setChildNeedsLayout()? That does seem to resolve the speed issues I was noticing as a result of this bug. Or do you mean to perform the same checks as the body tag path as well? Either way, I don't understand why setChildNeedsLayout() is better here :).
Comment on attachment 11941 [details] only call setNeedsLayout(true) if the view's size has changed The WebKit side of the WIndows code is buggy and it is causing layout() on FrameView to get called when it shouldn't. Cursor blinking should not cause you to re-enter layout, but it does so because WebView on Win32 is buggy. You should not technically even have to patch any cross-platform code to fix the Windows bug.
Shouldn't the code still be fixed to use setChildNeedsLayout() instead of setNeedsLayout()? That's still a bug with the WebCore code (it also has the benefit of helping the buggy Windows repaint issue).
Created attachment 12308 [details] call setChildNeedsLayout on framesets
Comment on attachment 12308 [details] call setChildNeedsLayout on framesets Hyatt says this is ok. r=him.
Landed in r19170.