Bug 118411 – absolute element with drop-shadow is not repainted when relative parent moves.

• Component: New Bugs
• Status: ASSIGNED

[Stefan Kuip]

Created attachment 206140 [details]
Absolute element with drop-shadow not repainted.

When the parent moves, the absolute positioned element within is not updated when there is drop-shadow on it.

It happens on the following browsers:

Macintosh WebKit-SVN-r152407
Macintosh Chrome 27.0.1453.116
Macintosh Safari 6.0.5 (8536.30.1)
Apple iPod Safari
Android Chrome 27.0.1453.90 (WebKit 537.36 (@150101))

[zalan]

repaint region issue: forcing full screen repaint moves the element.

[zalan]

Created attachment 206432 [details]
reduced test case

[zalan]

It looks like we ignore repainting anything with CSS3 filter on that requires full layer image (blur, drop shadow atm), when the parent layer gets moved around.  (Only the parent gets repainted)
This is related to bug 80323. 
r112745 limits the repaint container to the render layer where the filter is present, while judging by intention of that changeset, it should be more permissive in general. The idea of that fix is that the repaint rects should at least cover the entire layer (as opposed to a subset of it) in order to be able to apply the filter properly. 
However, when the repaint container is limited to the current render layer, while calculating the repaint rects, we miss anything parent related (in this case offsetForInFlowPosition() of the parent). This leaves the current layer non-dirty and painting behaves as if nothing had happened. -> no repaint.
Something like this fixes the core repaint issue (and surely no functionality regression as we are more permissive), but not sure if this is the right direction in general.

--- a/Source/WebCore/rendering/RenderObject.cpp
+++ b/Source/WebCore/rendering/RenderObject.cpp
@@ -1291,10 +1291,10 @@ RenderLayerModelObject* RenderObject::containerForRepaint() const
 #endif
     
 #if ENABLE(CSS_FILTERS)
-    if (document()->view()->hasSoftwareFilters()) {
+    if (document()->view() && document()->view()->hasSoftwareFilters()) {
         if (RenderLayer* parentLayer = enclosingLayer()) {
             RenderLayer* enclosingFilterLayer = parentLayer->enclosingFilterLayer();
-            if (enclosingFilterLayer)
+            if (enclosingFilterLayer && (!repaintContainer || repaintContainer->isDescendantOf(enclosingFilterLayer->renderer())))
                 return enclosingFilterLayer->renderer();
         }
     }

After fixing the core issue, we still need to look at it a bit more to extend the repaint rect to cover the effect (see attachment)

[zalan]

Created attachment 206527 [details]
partial repaint screenshot

[Ahmad Saleem]

I am able to reproduce in Safari Technology Preview 153 using "reduced test case" and in this once the animation makes container move, I can see container "white" wash and that there was element here while it is not the case for other browsers (Chrome Canary 107 and Firefox Nightly 106).

I am not sure whether "partial repaint" is same as this what I am seeing but just wanted to share updated results. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/99828676>

[Fujii Hironori]

*** Bug 236609 has been marked as a duplicate of this bug. ***

[Fujii Hironori]

WIP patch: https://github.com/WebKit/WebKit/pull/5047

[ujwal koneru]

New PR: https://github.com/WebKit/WebKit/pull/5299

I found couple of filter test cases that should cover this scenario. Testing with them.

[Ahmad Saleem]

Hi Alan - I found something related fixed in Blink, which might be easier drop-in to fix the issue.

Can you have a quick look into Bug 247961? Right now, I am trying to merge it to related / equivalent places but I think if we do it on this line, it would have same effect:

https://github.com/WebKit/WebKit/blob/9edba0422e4631c987c20c2217e26710c0d9c8a4/Source/WebCore/rendering/RenderLayer.cpp#L3228

Like here when we use filterContext, we use directly "paintingInfo" rather than "localPaintingInfo"?

I am trying it with Blink merge in Bug 247961 in following PR - https://github.com/WebKit/WebKit/pull/6531

Please ignore me if I am mixing bugs and no where close to understanding this. Thanks!

[zalan]

(In reply to Ahmad Saleem from comment #10)
> Hi Alan - I found something related fixed in Blink, which might be easier
> drop-in to fix the issue.
> 
> Can you have a quick look into Bug 247961? Right now, I am trying to merge
> it to related / equivalent places but I think if we do it on this line, it
> would have same effect:
> 
> https://github.com/WebKit/WebKit/blob/
> 9edba0422e4631c987c20c2217e26710c0d9c8a4/Source/WebCore/rendering/
> RenderLayer.cpp#L3228
> 
> Like here when we use filterContext, we use directly "paintingInfo" rather
> than "localPaintingInfo"?
> 
> I am trying it with Blink merge in Bug 247961 in following PR -
> https://github.com/WebKit/WebKit/pull/6531
> 
> Please ignore me if I am mixing bugs and no where close to understanding
> this. Thanks!
Hi, I'd ping Simon on these issues. He is a better candidate to look into RenderLayer related merges.