[Webkit-unassigned] [Bug 92800] Table test is invalidating the wrong rect

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 31 16:30:25 PDT 2012


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





--- Comment #9 from Eric Seidel <eric at webkit.org>  2012-07-31 16:30:25 PST ---
(In reply to comment #8)
> It appears that RenderBlock::layoutBlockChild doesn't set the child's logical top until after its laid out the block child.  In this case, after the table has been laid out.
> 
> So this explains why the table is laying itself out at 0,0, including the cells.  What's not clear to me is how render objects normally prevent themselves from not invalidating their "previous" paint position when painting for the first time.
> 
> RenderBlock::layoutBlock has this:
> 
>     LayoutRepainter repainter(*this, everHadLayout() && checkForRepaintDuringLayout());
> 
> everHadLayout() is presumably supposed to disable the repaint check for the first layout?
> 
> In the callstack I'm seeing the repaint call from, the render block inside the table cell has m_everHadLayout == 1.  Unclear why.

Interesting...

bool RenderObject::checkForRepaintDuringLayout() const
{
    // FIXME: <https://bugs.webkit.org/show_bug.cgi?id=20885> It is probably safe to also require
    // m_everHadLayout. Currently, only RenderBlock::layoutBlock() adds this condition. See also
    // <https://bugs.webkit.org/show_bug.cgi?id=15129>.
    return !document()->view()->needsFullRepaint() && !hasLayer();
}

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



More information about the webkit-unassigned mailing list