Bug 5768

Summary:

pages with frames that are all "fixed" get no layout and are blank (like www.farnell.nl)

Product:

WebKit

Reporter:

Henk <henk.kampman>

Component:

Layout and Rendering

Assignee:

Dave Hyatt <hyatt>

Status:

RESOLVED FIXED

Severity:

Critical

CC:

dbates, gabriel, mitz

Priority:

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

URL:

http://www.farnell.nl/

Attachments:

Description	Flags
Proposed patch	none
Equivalent patch without all the indenting	darin: review+
unsuccesful attempt at automatic testing	none

Henk

Reported 2005-11-18 00:16:21 PST

Goto http://www. farnell.nl/ Click on one of the buttons (NIEUWE PRODUCTEN, PUBLICATIES,ED WORLD,SUPPORT,ZOEK) at the top of the page. The corresponding page is loaded, but nothing is visible. However the content will appear when you click once in the window content region.

Attachments
Proposed patch (4.50 KB, patch) 2005-11-19 15:26 PST, mitz	no flags	Details Formatted Diff Diff
Equivalent patch without all the indenting (911 bytes, patch) 2005-11-22 22:02 PST, mitz	darin: review+	Details Formatted Diff Diff
unsuccesful attempt at automatic testing (1.36 KB, application/octet-stream) 2005-11-30 12:19 PST, mitz	no flags	Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

mitz

Comment 1 2005-11-19 13:37:46 PST

I reduced it to the noresize attribute of the frame element. When it's present, even the simplest testcase of <html> <frameset> <frame src="frame1.html" noresize> </frameset> </html> with frame1.html linking to frame2.html and vice versa results in frame content not appearing after the second switch (dragging in the empty frame behaves like a resize, after which the content is visible again). Without the noresize attribute, content does not disappear. When content is invisible, it's because the RenderFrame is at -500000. It is marked as needing layout but nothing triggers layout for it.

mitz

Comment 2 2005-11-19 15:26:50 PST

Created attachment 4736 [details] Proposed patch Don't skip layout even if all children are fixed.

Darin Adler

Comment 3 2005-11-22 19:55:15 PST

Comment on attachment 4736 [details] Proposed patch I was fooled by the formatting changes into thinking this was a bigger change than it is. The substance of this change is simple, and clearly a good idea. But can't we just move the end2: label up one line to get the same effect? I don't see a lot of value in indenting all the code.

mitz

Comment 4 2005-11-22 22:02:44 PST

Created attachment 4778 [details] Equivalent patch without all the indenting (In reply to comment #3) > But can't we just move the end2: label up one line to get the same effect? I > don't see a lot of value in indenting all the code. Just moving end2: up one line will cause RenderContainer::layout() to be called even when there are no children at all. I don't know how significant this is. This patch is equivalent to the previous patch.

mitz

Comment 5 2005-11-22 22:17:00 PST

Comment on attachment 4778 [details] Equivalent patch without all the indenting I'm leaving the r+ on the other patch, but if you prefer this version, please remove it.

Darin Adler

Comment 6 2005-11-23 06:42:59 PST

Comment on attachment 4778 [details] Equivalent patch without all the indenting Excellent. Seems much clearer this way.

Eric Seidel (no email)

Comment 7 2005-11-29 19:38:18 PST

It would be good to have a ready-to-land test case for this.

mitz

Comment 8 2005-11-30 12:19:33 PST

Created attachment 4882 [details] unsuccesful attempt at automatic testing This test works (automatically) in Safari, but I couldn't get it to work in DumpRenderTree. Perhaps relayout needs to be forced at some points, which I don't know how to do. Posting it here in hope that it will inspire someone else.

Darin Adler

Comment 9 2005-12-17 20:20:53 PST

I tried really hard to make that test work under DumpRenderTree, but I wasn't able to figure it out. There's something about how layout is done for repainting that seems to be required. I spent quite a while debugging both DumpRenderTree and Safari to see what's different between the two but it was ultimately fruitless.

mitz

Comment 10 2005-12-28 04:49:32 PST

*** Bug 5591 has been marked as a duplicate of this bug. ***

Gustaaf Groenendaal (MysteryQuest)

Comment 11 2006-03-08 10:32:20 PST

*** Bug 4110 has been marked as a duplicate of this bug. ***

Daniel Bates

Comment 12 2011-05-04 14:42:14 PDT

For completeness, this bug was fixed in changeset 11648 <http://trac.webkit.org/changeset/11648>.

Note You need to log in before you can comment on or make changes to this bug.