1740658 - Unexpectedly-wide flex item, when child has large intrinsic size but is constrained by aspect-ratio and cross-axis fixed size on flex container

Status: NEW

(Core :: Layout: Flexbox, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.

EXPECTED RESULTS:
50x50 black-bordered box, filled with lime. No red visible.

ACTUAL RESULTS:
The black-bordered box is 202px wide (including the border), and red is visible to the right of the lime.

Filing this for an issue identified in webcompat bug https://github.com/webcompat/web-bugs/issues/92564 .

Chrome gives ACTUAL RESULTS [edit: I think I meant to say "Chrome gives EXPECTED RESULTS"] Quoting myself from the webcompat bug report: I think Chrome is probably-correct here; .swiper-slide ultimately has a definite height, since it is (by default) a stretched flex item in a flex container whose cross-size is definite (its parent has height:50px). So the final layout should be the same as if .swiper-slide had height: 50px up-front, essentially. And that doesn't match our behavior; if I give .swiper-slide an explicit height: 50px, then we change to match Chrome.

This is causing an issue with the slideshow at https://glassen.ro/usi , as discussed in the webcompat bug report.

Comment 1

[Daniel Holbert [:dholbert]]

(TYLin suggests this might be related to bug 1711823, though the patch currently posted there doesn't fix the issue with the testcase here, so it's not necessarily an exact duplicate.)

Comment 2

[Ksenia Berezina [:ksenia] on leave until 09/15]

Setting webcompat priority as P3 as this is affecting one site at the moment.

Comment 3

[Thomas Wisniewski [:twisniewski]]

The one known affected site is no longer up, so clearing webcompat priority until we learn of other affected sites.