152588 2015-12-29 12:02:33 -0800 Webkit not recalculating width when changing height of absolute-positioned div with image 2021-10-16 23:30:32 -0700 1 1 1 Unclassified WebKit Layout and Rendering WebKit Nightly Build All All RESOLVED FIXED P2 Normal --- 1 lugnuts25 webkit-unassigned dbates hyatt rbuis simon.fraser zalan oldest_to_newest 1151556 0 267987 lugnuts25 2015-12-29 12:02:33 -0800 Created attachment 267987 Page that demonstrates bug StackOverflow issue, has an example you can run: http://stackoverflow.com/questions/34506314/webkit-bug-rendering-image-in-centered-absolute-div Basically I have a relatively position div, with a absolutely positioned div child. Inside the absolutely positioned div is a (square) image: <div relative> <div absolute> <img /> </div> </div> Both absolute and img have height: 100%, so when relative changes height, so should both children. The image should then recalculate it's width to preserve it's aspect ratio, which in turn will change its parent (absolute) to change width. However, when relative's height is changed (via javascript or the debugger) the widths are not properly updated. If relative's height is decreased, no widths are recalculated and the image becomes squished vertically. if relative's height is increased, the image's width is increased to maintain the aspect ratio, but its parent (absolute) does not increase width, causing the image to overflow and be displaced to the right (in the example, it should stay centered). Attached is an example page that shows this bug (also included in the stackoverflow). 1151770 1 268055 zalan 2015-12-31 14:02:05 -0800 Created attachment 268055 Test reduction 1151818 2 zalan 2015-12-31 18:05:21 -0800 (In reply to comment #0) > Created attachment 267987 [details] > Page that demonstrates bug > > StackOverflow issue, has an example you can run: > http://stackoverflow.com/questions/34506314/webkit-bug-rendering-image-in- > centered-absolute-div > > Basically I have a relatively position div, with a absolutely positioned div > child. Inside the absolutely positioned div is a (square) image: > <div relative> > <div absolute> > <img /> > </div> > </div> > > Both absolute and img have height: 100%, so when relative changes height, so > should both children. The image should then recalculate it's width to > preserve it's aspect ratio, which in turn will change its parent (absolute) > to change width. However, when relative's height is changed (via javascript > or the debugger) the widths are not properly updated. If relative's height > is decreased, no widths are recalculated and the image becomes squished > vertically. if relative's height is increased, the image's width is > increased to maintain the aspect ratio, but its parent (absolute) does not > increase width, causing the image to overflow and be displaced to the right > (in the example, it should stay centered). > > Attached is an example page that shows this bug (also included in the > stackoverflow). You could add "-webkit-aspect-ratio: from-intrinsic;" to your img element to preserve ratio. 1151821 3 zalan 2015-12-31 18:21:27 -0800 It looks like we don't dirty the preferred min width on the image renderer, so we always end up with the original width. 1151901 4 zalan 2016-01-01 21:26:45 -0800 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()) setChildrenInline(true); + dirtyForLayoutFromPercentageHeightDescendants(); if (childrenInline()) layoutInlineChildren(relayoutChildren, repaintLogicalTop, repaintLogicalBottom); else @@ -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? 1154548 5 zalan 2016-01-11 16:53:13 -0800 (B)lock/(I)nline/I(N)line-block, (R)elative/A(B)solute/Fi(X)ed/Stick(Y) positioned, (O)verflow clipping, (A)nonymous, (G)enerated, (F)loating, has(L)ayer, (C)omposited, (D)irty layout, Dirty (S)tyle B--AG-L- --* RenderView (0.00, 0.00) (1323.00, 455.00) renderer->(0x11596c580) B-----L- -- HTML RenderBlock (0.00, 0.00) (1323.00, 455.00) renderer->(0x1159ee678) node->(0x1159f1680) B------- -- BODY RenderBody (8.00, 8.00) (1307.00, 439.00) renderer->(0x1159ee730) node->(0x1159f1750) B------- -- DIV RenderBlock (0.00, 0.00) (1307.00, 100.00) renderer->(0x1159ee7e8) node->(0x1159f17b8) B------- -- DIV RenderBlock (0.00, 0.00) (1307.00, 100.00) renderer->(0x1159ee8a0) node->(0x1159f1888) -------- -- RootInlineBox (0.00, 86.00) (200.00, 18.00) (0x11a7dc888) renderer->(0x1159ee8a0) -------- -- InlineBox (0.00, 0.00) (200.00, 100.00) (0x11a7e62d0) renderer->(0x1159da420) I------- -- IMG RenderImage (0.00, 0.00) (200.00, 100.00) renderer->(0x1159da420) node->(0x11595e160) 1208326 6 lugnuts25 2016-07-06 12:20:24 -0700 I noticed that in AppleWebKit/537.36 (I do not know if that is the same vendor as this site) the image width now correctly updates to stay proportional, however the parent absolute still does not update it's width, causing the image to be left-ish-aligned instead of center-aligned 1803661 7 rbuis 2021-10-13 00:21:17 -0700 I am not sure this can be reproduced these days? 1805362 8 lugnuts25 2021-10-16 23:30:32 -0700 Seems that this issue is fixed. I can no longer produce any unexpected behavior. 267987 2015-12-29 12:02:33 -0800 2015-12-29 12:02:33 -0800 Page that demonstrates bug webkit-bug.html text/html 2079 lugnuts25 PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPjx0aXRsZT5XZWJraXQgYnVnPC90aXRsZT48 L2hlYWQ+CiAgPHN0eWxlPgogICAgI2NoYW5nZXNIZWlnaHQgewogICAgICBwb3NpdGlvbjogcmVs YXRpdmU7CiAgICB9CiAgICAKICAgICNjaGlsZCB7CiAgICAgIHBvc2l0aW9uOiBhYnNvbHV0ZTsK ICAgICAgbGVmdDogNTAlOwogICAgICBoZWlnaHQ6IDEwMCU7CiAgICAgIHRyYW5zZm9ybTogdHJh bnNsYXRlWCgtNTAlKTsKICAgIH0KICA8L3N0eWxlPgogIDxib2R5PgogICAgPGRpdiBpZD0iY2hh bmdlc0hlaWdodCIgc3R5bGU9ImhlaWdodDogMjAwcHg7Ij4KICAgICAgPGRpdiBpZD0iY2hpbGQi PgogICAgICAgIDxpbWcgc3R5bGU9ImhlaWdodDogMTAwJSIgc3JjPSJkYXRhOmltYWdlL2dpZjti YXNlNjQsUjBsR09EbGhNZ0F5QUlRUUFDWWFFbFFnRWxFWWJib1VDZzFMQ1pJOENPUXFPdUZJQml5 Zng5R0ZMV1N1QzhDaFE5MmNmK0svQ04yM2YrbktzUC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vL3lINUJBRUtBQkFBTEFBQUFBQXlB RElBQUFYKzRDT081TWljanZrNGpNTW1SY0E4WjEwYkJXNGNRNXVVUUJHcnBtb3hFb3pDaVhZeU5C bk9YZUZ3VFB5Q3dLRm90cklWdnJPYkV3cWQ5aHlKeGhWYjBtNkZweGdYYXFqWHl3ZXFPcDF3c1Vs SlhFd25BUUZ5VFhhSlUwcG9mSDErZnlJeWdnS1ZsaktKZGdNRGRYb0hlMm91TENsL0FqSWlscFVC QUppWm13TUZQVmFnVnFJcHBGaVZUYW1WQUhSMW5BYXZBd2tIVm83SGFMYTRKYnpPQUpuQW03RjVl V3A3ank1R2tNM09xZEN1cnp2VnhzZTEyWDYzM2Q2OTRRTUJBK1RWNW8rUExhTWxET3lYN3ZIeWVm VFEzVm9tQXNFK1ZZbUdrWXUzSTU0Vlk4cVFhQk9sUU1FQ0dnY0Z1RnZJWTFPZUw4blNLQnZGWUVG RkFnRCtNaWIweUtQbE1KQzFJcUpwc0t6aXlZUGlXTVlieHRJWVJFYzBaeTBZYXZQbU4xT3NlUHBU U0s3WUp4K05FaXlRT3BSQVVac3BBV2pkbXRSUXg1NEF3d0pzUU5iUlZKTUtyS1k5eWJYdEtxMytt dnFVbTRhczNiSW1yYXBsMjdadkFIbE81d0YyY0xjd1dadDYreXFlTXZlZldJaUdJOTk5cTVnVkFM bVAvMG1WekhtQjRrS2dZWEMraHFUMDVzaDFHeXdnTy9YTEt0QU1mTlZZUFpxbU9zS3BWZXVlWmVX TDd4Z0JIZ0FRUVdDRXlkcTRvcEltM2RzM0xOY01DRWgvZ1BnQmd1c0tPS2Q3SUhXVzZnVU9Gdnhl NUhxVjlQTkZyNnRIUU4zd1JWSldobzVDTTVSOCtiZlNBVWkvdW41OTlydTJETlhITVZQUjl4dG9X cDMraDlKZU52VzNYbUczQUZWZ0gxUEJBQngrQ2pLSW1JUHIwU1lLYitkRWxRQ0NDZWFIRWdJYVZz VGhlaXQ4MkIxOXgxUVJ3MVlaU3NmQVZlbXhpSVdJRlpwVGdCVVltcWdmQUE3Z2VKSjZrU0JqUlJL bHVhWmZqVU1hdVNGN2Z3VGtZMjhCa0lLaWtBaWdaZVJGa1hCSHo0OC9ZcmxNQ2tLdWxoMUJLNFFK dzV0WGZySGRmQXVnbENVeldTUjVESmtQeWRubW1XaWdKTWdJa0pDQ0p3bStGZE1uR0xhMDJBSjRW dmlDcDZHM1lRRkFvbVYrQWQ1QUxJQlhVa2tKU0pwRm8yMEdvUldmendFcUNuaERCZUJaQVVMRXVx cHQzSkNnbFNFV3VocmdVUEtGVjVKNFJQN1pvZ3VzMG5yb3JlVEpaOUZhVnZFcVhuMlhHdG9pZUEx NUZFVVRlQ1djNnB1WE5VcTNLUUVDaXJwTXRWS0NPWUsyQVhSYm8wV3RMckRLRDZMUWxKMlVGUzBn aUxZS3ByVmZqYzY2Q3dDMlJkSjdGYmcwQ0FmYXZ1cG1XT2VJQUR4eUZibjB1aXNDSyttaWx6Qy9x MUJyRThRQ0t5QURBaVd1bS9DVG52MXJKTWM0SmdheXhSZG4rQ1FyS0cvYzhZa2hBQUE3IiAvPgog ICAgICA8L2Rpdj4KICAgIDwvZGl2PgogICAgPGlucHV0IHN0eWxlPSJwb3NpdGlvbjogZml4ZWQ7 IHRvcDogMDsgbGVmdDogMCIgdHlwZT0ibnVtYmVyIiB2YWx1ZT0iMjAwIj4KICAgIDxzY3JpcHQ+ CiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdpbnB1dCcpWzBdLm9uY2hhbmdl ID0gZnVuY3Rpb24oYSkgewogICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdjaGFuZ2Vz SGVpZ2h0Jykuc3R5bGUuaGVpZ2h0ID0gdGhpcy52YWx1ZSArICdweCc7CiAgICAgIH07CiAgICA8 L3NjcmlwdD4KICA8L2JvZHk+CjwvaHRtbD4K 268055 2015-12-31 14:02:05 -0800 2015-12-31 14:02:05 -0800 Test reduction bug-152588.html text/html 411 zalan PHN0eWxlPgogICNjaGlsZCB7CiAgICBoZWlnaHQ6IDEwMCU7CiAgICBib3JkZXI6IDFweCBzb2xp ZCBncmVlbjsKICB9Cjwvc3R5bGU+CmltZyBzaG91bGQgcHJlc2VydmUgYXNwZWN0IHJhdGlvIGFm dGVyIGNvbnRhaW5lciByZXNpemUuCjxkaXYgaWQ9ImNoYW5nZXNIZWlnaHQiIHN0eWxlPSJoZWln aHQ6IDIwMHB4OyI+CiAgPGRpdiBpZD0iY2hpbGQiPjxpbWcgc3R5bGU9ImJvcmRlcjogMXB4IHNv bGlkIHJlZDsgaGVpZ2h0OiAxMDAlIiBzcmM9Im5vdGZvdW5kLmpwZyI+PC9kaXY+CjwvZGl2Pgo8 c2NyaXB0PgogIHNldFRpbWVvdXQoZnVuY3Rpb24oKSB7CiAgICBkb2N1bWVudC5nZXRFbGVtZW50 QnlJZCgnY2hhbmdlc0hlaWdodCcpLnN0eWxlLmhlaWdodCA9ICIxMDBweCI7CiAgICB9LCAxMDAp Owo8L3NjcmlwdD4K