1973612 - Firefox and Chrome differ on what `width: min-content` means for an element with an aspect-ratio and a large height

Status: NEW

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

[I'm not sure who's correct here, but AlaskanEmily and I noticed there's a behavior-difference here and I want to have a spot to post my testcases that render differently. This might result in a Chrome bug if we determine that Chrome is in the wrong here.]

STR:

1. Load attached testcase.

CHROME RESULTS:
Upper and lower teal boxes are the same size (both 60px wide).

FIREFOX RESULTS:
Upper teal box is 10px wide; lower teal box is 60px wide.

Comment 1

[Daniel Holbert [:dholbert]]

This behavior-difference is the reason that Chrome renders the final piece of this reftest differently from us:
https://searchfox.org/mozilla-central/rev/16a9e4fb2cfa1096c330f873d7d4b05666659c5d/layout/reftests/css-grid/grid-auto-min-sizing-min-content-min-size-002.html

The final piece has "min-height:40%; max-width:30px" (plus min-width: min-content). In Chrome, the specified min-height there causes the min-content width to be larger. In Firefox, the specified min-height does not cause the min-content width to be larger.

Comment 2

[Daniel Holbert [:dholbert]]

WebKit (Safari 18.5) agrees with Firefox here, FWIW. Not sure if that's because we're right vs. if they've just got the same bug (or are missing the same spec-update) that we are.

Comment 3

[Alice0775 White]

Regression window #1:
Good build:Upper and lower teal boxes are 60px wide.
Bad build: Upper and lower teal boxes are 10px wide.
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=e3cb278bc8a4dc19b3f3029ed40cb675c349c2ed&tochange=be5e54edad6088b4179c8c1b617664db62150388

Suspect: Bug 1322780

Regression window #2:
Former build: same as regression #1 (Upper and lower teal boxes are 10px wide)
Bad build: Upper teal box is 10px wide; lower teal box is 60px wide
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=6680e1d14c3e2d15663007e36c32ace46683b27f&tochange=8d542254e789a49e93c60cdf5e22fba2248f4d77

Suspect: Bug 1700640

Comment 4

[Daniel Holbert [:dholbert]]

Thanks for the regression ranges!

I don't consider either of those ranges to be "regressions", so I'm going to move them to the "dependencies" field. (We didn't really have the correct behavior before either of those ranges; we sorta did before #1, but only by accident, due to not supporting the width keyword involved at all and the default width:auto keyword happening to give the behavior that we're expecting here.)

(In reply to Alice0775 White from comment #3)

Regression window #1:
Good build:Upper and lower teal boxes are 60px wide.
Bad build: Upper and lower teal boxes are 10px wide.
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=e3cb278bc8a4dc19b3f3029ed40cb675c349c2ed&tochange=be5e54edad6088b4179c8c1b617664db62150388

Suspect: Bug 1322780

This one was just us-starting-to-recognize the testcase's width: min-content style at all. Presumably we behave the same going back further if I were to add width: -moz-min-content; as a fallback style to the testcase (probably not worth bothering to poke with that though).

Regression window #2:
Former build: same as regression #1 (Upper and lower teal boxes are 10px wide)
Bad build: Upper teal box is 10px wide; lower teal box is 60px wide
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=6680e1d14c3e2d15663007e36c32ace46683b27f&tochange=8d542254e789a49e93c60cdf5e22fba2248f4d77

Suspect: Bug 1700640

Interesting! I actually spun this bug off of poking at a testcase for <img>, and I switched to <canvas> for convenience (since it's slightly easier to manually set the intrinsic size of a canvas). But it looks like we arrived at our current behavior at different times for different replaced elements.

I'll attach a testcase with img shortly. For that one, we switched from the "Upper and lower teal boxes are 10px wide" behavior to the "Upper teal box is 10px wide; lower teal box is 60px wide" behavior only last year in bug 1670151. I'll add that as a dependency too.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: using a purple `img` now (and with fallback `-moz-min-content`)

Here's a testcase with img, which arrived at our current behavior in bug 1670151 as discussed above.

(Prior to bug 1670151, we rendered both img elements in this testcase as being 10px wide, which was more-wrong. Arguably we should be rendering both of them as 60px wide, perhaps. Bug 1670151 fixed this for width: max-content; height: [something] but we may need to fix it for min-height: [something] as well.