[Webkit-unassigned] [Bug 81114] ASSERT(!needsLayout()) in FrameView::paintContents() with multiple nested iframes, when frame flattening is on

Wed Mar 14 09:43:12 PDT 2012

https://bugs.webkit.org/show_bug.cgi?id=81114

--- Comment #1 from Zalan Bujtas <zbujtas at gmail.com>  2012-03-14 09:43:12 PST ---
steps leading to assertion:

1, When the bottommost iframes loads, FrameView/RenderView are constructed and get marked dirty. (markContainingBlocksForLayout )
2, Parser stops at the script element.
3, Viewport requests painting.
5, updateLayoutAndStyleIfNeededRecursive(mainframe) is called to clean the render tree recursively before performing painting.
4, At this point only the newly constructed, bottommost FrameView is dirty. Both its parent and its parent's parent (mainframe) are clean (due to previous layouts)
5, layout() is called on the bottommost FrameView, which in turn re-initiates the layout flow from the topmost FrameView and expects that the layouting will reach itself.
6, Since parent FrameViews are clean, layouting stops at the topmost frame.
7, Bottommost FrameView's layout returns with dirty tree.

No assertion happens:
1, When the blocking resource is not present and parsing hits <body>.
HTMLBodyElement::insertedIntoDocument() schedules relayout on the current (bottommost) FrameView, which in turn marks its parent dirty.

2, When there's one less nested iframe.
The layout works accidentally in this case. At step 6, when layout(mainframe) performs post layout tasks, it calls updateWidgetPositions(), which eventually calls layout on direct (dirty)child frames. So getting the bottommost tree clean does not happen as the result of the normal layout flow (FrameView(mainframe)->RenderView->...->RenderIFrame->FrameView(child)), but as the result of perform post layout task.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.