Bug 94964 – Repaint issue in vertical-rl content

• Component: Layout and Rendering
• Status: NEW

[Simon Fraser (smfr)]

Created attachment 160465 [details]
Testcase

Attached testcase shows a repaint issue with positioned elements inside vertical-rl content.

[Simon Fraser (smfr)]

In RenderBox::computeRectForRepaint(), we do:

        topLeft += layer()->offsetForInFlowPosition();

offsetForInFlowPosition() is physical, so this seems wrong.

[Simon Fraser (smfr)]

Maybe fix, but we probably need something like this in lots of other places too:


diff --git a/Source/WebCore/rendering/RenderBox.cpp b/Source/WebCore/rendering/RenderBox.cpp
index 1a1714f..480e19f 100644
--- a/Source/WebCore/rendering/RenderBox.cpp
+++ b/Source/WebCore/rendering/RenderBox.cpp
@@ -1580,9 +1580,17 @@ void RenderBox::computeRectForRepaint(RenderBoxModelObject* repaintContainer, La
     else if ((position == RelativePosition || position == StickyPosition) && layer()) {
         // Apply the relative position offset when invalidating a rectangle.  The layer
         // is translated, but the render box isn't, so we need to do this to get the
-        // right dirty rect.  Since this is called from RenderObject::setStyle, the relative position
+        // right dirty rect. Since this is called from RenderObject::setStyle, the relative position
         // flag on the RenderObject has been cleared, so use the one on the style().
-        topLeft += layer()->offsetForInFlowPosition();
+        LayoutSize offset = layer()->offsetForInFlowPosition();
+        if (style()->isFlippedBlocksWritingMode()) {
+            if (style()->isHorizontalWritingMode())
+                offset.setHeight(-offset.height());
+            else
+                offset.setWidth(-offset.width());
+        }
+        
+        topLeft += offset;
     }
     
     if (o->isBlockFlow() && position != AbsolutePosition && position != FixedPosition) {

[Simon Fraser (smfr)]

Notes from discussion with hyatt: topLeft is really minXYPoint. Negating the offsets is correct, probably want a helper to do that.

[Dave Hyatt]

Yeah, this is essentially identical to text shadow visual overflow, which is also in the local block's coordinate space. You can see that since text shadow offsets are physical, we essentially have to negate the shadow offset along the axis of the flip.

We need to do this same kind of negation for any relative position/sticky position offsets that are added in to local block coordinates.

[Ahmad Saleem]

I am still able to reproduce this bug in Safari 16.1 / STP 157 using attached test case where it moves to 50 px and change color but the rectangle does not go above 'AFTER' to hide it. So from 'rectangle' / 'square', it becomes just halved till AFTER.

Chrome Canary 110 and Firefox Nightly 108 match each other and shift rectangle above 'AFTER' and hide it on left side.

NOTE - I modified test case to remove -webkit- to make it work in Firefox.

Link - https://jsfiddle.net/a75webrg/show

Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/122587980>