[Webkit-unassigned] [Bug 116994] Setting overflow:hidden on position:absolute does not repaint hidden content

Sun Jun 9 20:29:35 PDT 2013

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

--- Comment #15 from Yuki Sekiguchi <yuki.sekiguchi at access-company.com>  2013-06-09 20:28:09 PST ---
(In reply to comment #13)
> (From update of attachment 203661 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=203661&action=review
> 
> > Source/WebCore/ChangeLog:18
> > +        In the reproduced content, overflow:hidden parent(called P) has display:none replaced child(called C).
> > +        If we hover a element, P becomes overflow:visible, and C becomes display:block.
> > +        If we mouse out from the element, P becomes hidden, and C becomes none, and part of C is not repainted.
> > +
> > +        When we mouse out from the element, P and C request repaint.
> > +        Before requesting repaint, P becomes overflow: hidden, and it makes hasOverflowClip() true.
> > +        Requesting repaint from C is clipped by P at RenderBox::computeRectForRepaint().
> > +        The rect which P requests repaint is content rect of P, so the rect which is overflowed from P is not requested.
> > +
> > +        If C is not relative, visual overflow rect of P has the rect of C, so we can repaint well.
> > +        If C doesn't become display:none, layouting C requests repaint the rect of C, so we can repaint well.
> 
> I don't think this long explanation is necessary.

Removed.

> 
> > Source/WebCore/rendering/RenderLayerModelObject.cpp:82
> > +    return !hasSelfPaintingLayer() && container->hasOverflowClip();
> 
> You should ASSERT that o is the container.

Added.

> 
> > LayoutTests/fast/repaint/change-overflow-and-display-of-relative-expected.html:2
> > +<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> 
> Don't need the <meta> tag.

Removed, and added closing tag of head.

> 
> > LayoutTests/fast/repaint/change-overflow-and-display-of-relative.html:32
> > +        }, 50);
> 
> Can this be < 50ms?

No, this can't.
I tried 0ms and used "overflow.offsetHeight;" to force to redraw.
However, if I open this test from Finder, the problem is sometimes not reproduced.
I think 1st drawing is combined with 2nd drawing.

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