[Webkit-unassigned] [Bug 93703] New: fast/repaint/float-in-new-block-with-layout-delta.html is overpainting

[bugzilla-daemon at webkit.org]

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

           Summary: fast/repaint/float-in-new-block-with-layout-delta.html
                    is overpainting
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: eric at webkit.org
                CC: mitz at webkit.org, simon.fraser at apple.com


fast/repaint/float-in-new-block-with-layout-delta.html is overpainting

Looking at the expected image:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/repaint/float-in-new-block-with-layout-delta-expected.png

Notice how we repaint 100x200 instead of 100x100 (which is actually all we need).

The "overpaint" is caused by:
RenderBlock::repaintDirtyFloats
which is called at the last line of:
RenderBlock::layoutRunsAndFloats

and repaints the float inside the div which is of course still at 0,0.

The problem appears to be the layoutDelta in:

LayoutRect RenderBox::clippedOverflowRectForRepaint(RenderBoxModelObject* repaintContainer) const
{
    if (style()->visibility() != VISIBLE && !enclosingLayer()->hasVisibleContent())
        return LayoutRect();

    LayoutRect r = visualOverflowRect();

    RenderView* v = view();
    if (v) {
        // FIXME: layoutDelta needs to be applied in parts before/after transforms and
        // repaint containers. https://bugs.webkit.org/show_bug.cgi?id=23308
        r.move(v->layoutDelta());
    }

Which at time of repaint is 0, -118, which adjusts the rect from the repaint() call back to 0.

It seems that the repaintDirtyFloats call is attempting to repaint the *new* location of the float, not the *old* location, but maybe I"m misunderstanding.

I'll have to look again to understand why we're actually invalidating the new location, although initial testing of my patch on bug 92800, may suggest that our invalidation of the new location is wrong, as bug 92800 disables it (possibly incorrectly).

The first issue is for me to understand what the purpose of RenderBlock::repaintDirtyFloats at the end of RenderBlock::layoutRunsAndFloats is.

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