[Webkit-unassigned] [Bug 152588] Webkit not recalculating width when changing height of absolute-positioned div with image

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 1 21:26:45 PST 2016


--- Comment #4 from zalan <zalan at apple.com> ---
diff --git a/Source/WebCore/rendering/RenderBlockFlow.cpp b/Source/WebCore/rendering/RenderBlockFlow.cpp
index 286649c..96ed8c2 100644
--- a/Source/WebCore/rendering/RenderBlockFlow.cpp
+++ b/Source/WebCore/rendering/RenderBlockFlow.cpp
@@ -479,6 +479,7 @@ void RenderBlockFlow::layoutBlock(bool relayoutChildren, LayoutUnit pageLogicalH
     LayoutUnit maxFloatLogicalBottom = 0;
     if (!firstChild() && !isAnonymousBlock())
+    dirtyForLayoutFromPercentageHeightDescendants();
     if (childrenInline())
         layoutInlineChildren(relayoutChildren, repaintLogicalTop, repaintLogicalBottom);
@@ -584,8 +585,6 @@ void RenderBlockFlow::layoutBlock(bool relayoutChildren, LayoutUnit pageLogicalH

 void RenderBlockFlow::layoutBlockChildren(bool relayoutChildren, LayoutUnit& maxFloatLogicalBottom)
-    dirtyForLayoutFromPercentageHeightDescendants();
     LayoutUnit beforeEdge = borderAndPaddingBefore();
     LayoutUnit afterEdge = borderAndPaddingAfter() + scrollbarLogicalHeight();

^^It fixes the issue of not dirtying the replaced renderer's preferred width when the (non-direct)ancestor height changes.

The failing test case has 
(A)RenderBlock with fixed height.
  (B)RenderBlock with percentage height
    (C)RenderImage with percentage height

When (A)'s height is changed, we recalculate (C)'s height but we keep the original width (so we might lose the original aspect ratio)

In this case, gPercentHeightDescendantsMap has the (B)->(C) pair -since (A) has non-auto, non-percentage height. By changing (A)'s height, all the renderers (A)(B) and (C) are correctly marked dirty. However the preferred width bit does not get dirty (C) because the RenderBlock only calls dirtyForLayoutFromPercentageHeightDescendants() on its block children only -while here, (B) only has an inline child (C) 
Dave, do you know why it was originally added only to the block children path?

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160102/8e16ebf2/attachment-0001.html>

More information about the webkit-unassigned mailing list