1377440 - Weird Flexbox behavior with images

Status: RESOLVED DUPLICATE of bug 1374540

(Core :: Layout: Flexbox, defect, P3)

Description

[r.gottesheim]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce:

See https://jsfiddle.net/2jjwgyhL/1/


Actual results:

When the output frame is made smaller, the images don't have the same height anymore.

Note that all of the images have the same "natural" height of 500 pixels.


Expected results:

The images have different heights.

I don't know if this is a bug in Chrome or in Firefox, but in Chrome the images always have the same height. Since Chrome's behavior is the desired one in my case, I'm filing this bug on your side.

Comment 1

[r.gottesheim]

By "made smaller" I mean narrowed.

Comment 2

[Alice0775 White]

The height issue is regressed by Bug 823483

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a further-reduced testcase (using <canvas> instead of <img> to make it more self-contained).

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Alice0775 White from comment #2)
> The height issue is regressed by Bug 823483

If I add "min-width:0" to the flex items in the jsfiddle or the attached testcase, then I can confirm that we do change from matching Chrome to not-matching-Chrome around the landing of that bug.  E.g. here's a modified version of the jsfiddle that demonstrates this:
 https://jsfiddle.net/2jjwgyhL/2/

(Without "min-width:0", we render flex items quite wide, before Bug 823483 landed.)

I think this *might* be a product of the fact that we do flexbox "measuring reflows" using the flex container's width as the containing-block width -- so "max-width:100%" has something nonzero to resolve against -- but we're really supposed to do that layout with unconstrained available space.  And this ends up influencing the content-based flex-basis that we use for our flex items which we start shrinking from.

I believe there's already a bug on this general issue, but I can't find it at the moment.

Comment 5

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 6

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

The testcase 1 in comment 3 works as expected. Mozregression finds this fixed range. I guess bug 1374540 fixed this bug, too.