Bug 220565 – WebKit uses the wrong intrinsic-size contribution for percent-width replaced elements

• Component: Layout and Rendering
• Status: NEW

[Daniel Holbert]

STR:
(1) Load https://jsfiddle.net/dholbert/r3dwmpsq/

EXPECTED RESULTS:
The third and fourth black boxes should be square -- they should have the same width as the first and second black boxes.

ACTUAL RESULTS:
The third and fourth black boxes are wide instead.


Firefox and EdgeHTML give my expected results here.
Chromium 89 and Safari 14 give me "Actual results".

The authoritative spec text here (which I believe requires my expected result) is css-sizing level 3, section 5.2.1 subsection "b":
https://drafts.csswg.org/css-sizing/#cyclic-percentage-contribution
> Intrinsic Contributions of Percentage-Sized Boxes
> When calculating the intrinsic size contribution of such a box, ... 	a percentage value that resolves against a size in the same axis as the intrinsic size contribution (a cyclic percentage size) is resolved specially:
> ...
>  if the box is replaced, then the entire value of any [...] preferred size property specified as an expression containing a percentage that is cyclic is treated for the purpose of calculating the box’s max-content contributions only as that property’s initial value. 

So that means that, in my jsfiddle here, the canvas's contribution to the black box's size should be the same for the first four boxes.  (In boxes #3 and #4, the canvases have percentage values which are considered cyclic by this spec section, and so their specified widths are to be treated as if they were the initial value when determining their intrinsic-size contribution to the width of their container; and so the container should end up the same size for those first four boxes.)

(Note: this is a bug that Chromium and WebKit share; it might go back to before the fork. The chromium version of this bug is https://bugs.chromium.org/p/chromium/issues/detail?id=1165896 ; I'm mostly copypasting the bug report to save myself some time.)

[Daniel Holbert]

Created attachment 417491 [details]
testcase 1 (same as jsfiddle in initial comment)

Here's a local version of the linked jsfiddle, BTW.

[Radar WebKit Bug Importer]

<rdar://problem/73371212>

[Smoley]

Thanks for filing, I can reproduce this on Safari 13.1.3, STP 118 and Google Chrome. Firefox does not reproduce this issue.

[Ahmad Saleem]

This issue is reproducible in Safari 15.5 on macOS 12.4. It is now fixed in Chrome and Chrome Canary 104 matches Firefox Nightly 102 behavior which is "Expected Results" as per bug report. Thanks!