Filing this bug for an inconsistency that came up in https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1218669239 . There might already be a bug on this, but I couldn't find one right away. (bug 1740658 is similar, but there, the flex item is also a flex container, and I think that bug (and bug 1742042) are really more about sizing of flex containers based on their contents, and are distinct from this issue here which is focused more on flex item automatic-min-size resolution.)

STR:

1. Load attached testcase and reference case, and compare their renderings.

ACTUAL RESULTS:
They look different.

EXPECTED RESULTS:
They should look the same.

Looking at the spec text at https://drafts.csswg.org/css-flexbox-1/#min-size-auto (mirror: https://andreubotella.com/csswg-auto-build/css-flexbox-1/#min-size-auto ), we should have both a "transferred size suggestion" of 200px and a "content size suggestion" of 100px in both cases, and we should be using the smaller one (100px) to give us the automatic minimum size.

So theoretically both of these cases should be rendering with a 100px wide by 200px tall purple area here, based on the spec, I think? (Talking to Tab and fantasai just now, I think that's their expectation as well.) However, Chrome renders both cases as 200px by 200px, which is consistent but seems to possibly disagree with the spec. (Though the spec may change in https://github.com/w3c/csswg-drafts/issues/6794 )

Note that the testcase and reference case here are identical, except for the way in which the definite cross-size is imposed on the flex item.

(In the testcase, the definite cross-size is imposed as an explicit height. In the reference case, it's imposed via cross-axis stretching. In the testcase, I suspect we're mistakenly letting the explicit height influence our measured content-width, via the fact that we construct a ReflowInput to resolve that size IIRC, and ReflowInput tries to be helpful by eagerly accounting for explicit sizes transferring through the aspect ratio.)

I haven't followed all the details yet, but comment 3 seems indicating that we shouldn't let aspect-ratio affects content-size suggestion. If so, we shouldn't land my patches in bug 1735589. (Note Bug 1735589 Part 1 allows aspect-ratio to affect content size suggestion when the main-axis is the block-axis).

To fix this bug, we can add sizeOverrides.mAspectRatio.emplace(AspectRatio()); after this line when computing content-size suggestion if the main-axis is the inline-axis.

Hmm, you're right; my initial leaning here seems to be the opposite of what bug 1735589 was about, i.e. the opposite of what I described in bug 1735589 comment 1.

Let's wait on taking action here until https://github.com/w3c/csswg-drafts/issues/6794 is settled (which will probably be on the Aug 31 call I think).

I think this interop-2023-relevant test failure is due to this bug:
https://wpt.fyi/results/css/css-flexbox/flex-minimum-height-flex-items-023.html

If I add an explicit width:100px to the img there (imposing an explicit cross size, rather than letting it resolve the cross size via stretching), then Firefox matches the test's expected results. That sounds like this bug here.

Also this one seems to be this same bug:
https://wpt.fyi/results/css/css-flexbox/flex-aspect-ratio-img-column-011.html

We fail the subtest for .flexbox 7, where the test is expecting an img to be 50px tall but we size it to 10px. The image element has a intrinsic size of 10x10, but it's stretched in the cross axis to a width of 50px, and the test is expecting that to prop up its automatic minimum size. If I give the image an explicit width:50px, then it does end up with the correct height of 50px. So this issue is specific to when the image is getting its cross size by being stretched, i.e. this bug here.