2064812 - Replaced elements (img, canvas, etc) with percent-valued height or width are sized to 0px as flex items in some cases (possibly due to being treated as "compressible" leading to min-height:auto resolving to 0px)

Status: NEW

(Core :: Layout: Flexbox, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase ("testcase 1")

ACTUAL RESULTS:
Lots of red, no lime-green.

EXPECTED RESULTS:
Black rectangle should be filled with lime-green.

I think this is the root of bug 2055777 - an image with a percent height is treated as having a resolved min-height of 0 in Firefox, whereas Chrome resolves the percentage and uses that as the min-height.

Spec reference:
https://drafts.csswg.org/css-flexbox-1/#min-size-auto

For replaced elements
Use the smaller of the content size suggestion and the transferred size suggestion (if one exists), capped by the specified size suggestion (if one exists).

Chrome and Firefox agree on using the transferred size suggestion (which is 180px).
The part where we differ is "...capped by the specified size suggestion (if one exists)."

We behave as if the specified size suggestion were 0px, essentially; whereas Chrome is resolving the specified height against the flex container's height, and using that as the cap.

Comment 1

[Daniel Holbert [:dholbert]]

This is sort-of a regression from bug 1585485:

• Before that bug's patch landed (e.g. Nightly 2020-12-17), we rendered a 10px tall lime area here, because we clamped min-height:auto to the replaced element's intrinsic height -- which is 10px, for the <canvas> in this testcase.
• After that bug's patch landed (e.g. in Nightly 2020-12-18), we render no lime at all here, because we resolve min-height:auto to 0px for the replaced element.

Comment 2

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

This looks very similar to bug 1938264 or bug 1956674.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

This is sort-of a regression from bug 1585485:

• Before that bug's patch landed (e.g. Nightly 2020-12-17), we rendered a 10px tall lime area here, because we clamped min-height:auto to the replaced element's intrinsic height -- which is 10px, for the <canvas> in this testcase.

Safari 27 still does this^, for what it's worth.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (same as 1, just with axes flipped)

Here's a testcase with the axes flipped, which still shows the same bug. (The percent width makes us resolve min-width:auto to 0px, whereas in Chrome the percent size resolves to the size of the container and serves as an upper-bound for the min-width:auto, clamping it to 100px).

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Ting-Yu Lin [:TYLin] (PST, UTC-7) from comment #2)

This looks very similar to bug 1938264 or bug 1956674.

Agreed. Though those bugs reference "an unresolvable percent" which is not something we've got here. It's possible that my testcase here is just a more-reduced version of what we've got over there, or they might be subtly different.

Adding to see-also for now, in any case.

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1585485