Weird Flexbox behavior with images

NEW
Unassigned

Status

()

Core
Layout
P3
normal
10 months ago
7 months ago

People

(Reporter: r.gottesheim, Unassigned)

Tracking

46 Branch
Points:
---

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox54 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 affected)

Details

(Whiteboard: [parity-Chrome][parity-Edge][DUPEME])

Attachments

(1 attachment)

(Reporter)

Description

10 months ago
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.
(Reporter)

Comment 1

10 months ago
By "made smaller" I mean narrowed.

Updated

10 months ago
status-firefox54: --- → wontfix
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox-esr52: --- → wontfix
Component: Untriaged → Keyboard: Navigation
Product: Firefox → Core
Whiteboard: [parity-Chrome][parity-Edge]
Version: 54 Branch → 46 Branch

Updated

10 months ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

10 months ago
The height issue is regressed by Bug 823483
Blocks: 823483

Updated

10 months ago
Component: Keyboard: Navigation → Layout
Created attachment 8883697 [details]
testcase 1

Here's a further-reduced testcase (using <canvas> instead of <img> to make it more self-contained).
(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.
Whiteboard: [parity-Chrome][parity-Edge] → [parity-Chrome][parity-Edge][DUPEME]

Updated

9 months ago
Priority: -- → P3
status-firefox55: affected → wontfix
status-firefox56: affected → wontfix
status-firefox57: --- → wontfix
status-firefox58: --- → affected
You need to log in before you can comment on or make changes to this bug.