[Webkit-unassigned] [Bug 73161] Absolute child is not repainted when parent opacity changes

[bugzilla-daemon at webkit.org]

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





--- Comment #1 from Philip Rogers <pdr at google.com>  2011-11-26 13:19:21 PST ---
Created an attachment (id=116664)
 --> (https://bugs.webkit.org/attachment.cgi?id=116664&action=review)
Fix Absolute child is not repainted when parent opacity changes

The previous patch (https://bugs.webkit.org/show_bug.cgi?id=68777) caused a regression because it affected both the composited and the non-composited code paths. Stackoverflow (sometimes) kicks the renderer into a composited path, which repainted incorrectly with the previous patch.

The actual bug only occurs when non-composited layers are encountered. To see this, add -webkit-transform:translateZ(0) to the test case (which creates composited layers) and the problem will go away. This new patch is updated to only affect the non-composited case.

Some details about what's actually going on...
The problem is in the order of style[Will/Did]Change and the diff calculation in RenderObject::setStyle().

1. Before styleWillChange().
RenderObject::adjustStyleDifference() should determine that the diff = StyleDifferenceLayout because there is no layer but one needs to be created.

2. In styleWillChange().
RenderBoxModelObject::styleWillChange() for the parent sees diff=StyleDifferenceLayout and calls repaint().

3. In styleDidChange().
A new RenderLayer is created for the parent.

4. After styleDidChange().
RenderObject::adjustStyleDifference() is called again, with all layers ready. If the layer is not composited, we set diff = StyleDifferenceRepaintLayer and force a full repaint including descendants. The previous patch would do this even for composited layers, which leaves dirty areas during scrolling.

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