1436180 - [css-grid][flex]Intrinsic size on grid-subflex / subbitem keeps the image width whilst image is resized.

Status: RESOLVED DUPLICATE of bug 1926015

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

Description

[Robert Utasi [:hunboy]]

Attachment: testcase with a constant cell height.

Motivation: some horizontally scrollable slider by flex in a grid cell.

AR: The resized <img> allocates the original size of the image.

ER: Like this fiddle: https://jsfiddle.net/9eb69gye/16/
    but images might be in a wrapper.

Although the image resized to the grid-cell's height, still allocates the original image width in the cell.

Crossbrowser compat: chromium looks ok by decreasing the width, although has other bug, scrollbar overlaps the content in Win10.

Testcase attached.

in the testcase the grid cell is sized to 100px, but should be work with 1fr value as well.

Comment 1

[Daniel Holbert [:dholbert]]

I'm betting that something like this is what's going on here:

 (a) the flexbox (#slides) isn't considering its height to be "definite", so it doesn't proactively stretch (shrink) its items (the images) in the cross axis.
 (b) ...so we resolve the items' main size to be the image's intrinsic size (kinda under the assumption that the image will actually get its inrinsic height)
 (c) ...but then in the final layout, it turns out the flex container *does* have a constrained height after all, so the images do as well, so their width is constrained.  But we've already determined their x-positions without that knowledge.

This is likely related to the spec change (or at least the spec text) in bug 1055354.  Probably best to fix this as part of sorting that issue out.  Marking as dependency.

Comment 2

[rsnow]

I think I'm running into this issue as well, see https://codesandbox.io/s/cool-yalow-kcfdq
The idea is that I want to maintain an aspect ratio of 1/1 which img should do with an explicit height set, and does in other places.
An interesting part to this is that if I inspect the dom and hover the SizeHelper img, it shows the correct size, but the grid has not responded in kind.
Sorry if I'm in the wrong ticket, it's a little hard to tell what's going on. I was torn between this one and https://bugzilla.mozilla.org/show_bug.cgi?id=1439527

Comment 3

[Albert Scheiner [:alberts]]

Do these look related?
https://stackoverflow.com/questions/48447154/css-grid-template-with-image-breaks-firefox
https://stackoverflow.com/questions/73971343/image-resize-overflows-css-grid-column-in-firefox

Comment 4

[Sky Schubert [:skyschub]]

This is still a valid issue as testcases still reproduce - however, we don't have any active non-testcase WebCompat breakage caused by this. Unsetting the webcompat-priority flags per our rules.

Comment 5

[alejandro9r]

I'm building a website and I've hit this bug. It does not happen in Chrome nor Safari. I tried to work around this in many other ways but to no avail. The only solution is to re-think the whole layout basically, which defeats the purpose of being very responsive.

Should I file a WebCompat issue with the site in question? The test page is https://martyrio.pages.dev in the very home page, at mobile screen widths, but soon will be live in an official domain.

By disabling max-width: 100% in the images, it stops overflowing but triggers the same bug as described in this thread, where for some reason the parent element takes the width from the intrinsic size of the images, instead of the recalculated one (even though the image looks fine, including in the Browser Inspector). It shouldn't have overflown either in the first place. This does not happen in the other browsers.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to alejandro9r from comment #5)

I'm building a website and I've hit this bug. It does not happen in Chrome nor Safari. I tried to work around this in many other ways but to no avail. The only solution is to re-think the whole layout basically, which defeats the purpose of being very responsive.

Should I file a WebCompat issue with the site in question?

Please do (ideally at https://bugzilla.mozilla.org/enter_bug.cgi?product=Web%20Compatibility&component=Site%20Reports ), and please include a screenshot or screencast showing the issue. (Those will be handy since I'm not sure I'm seeing or reproducing the issue you're describing - the page looks and behaves the same in Firefox and Chrome at first glance, testing in a mobile-sized desktop browser and on an actual Android phone.)

Comment 7

[alejandro9r]

Ok this is interesting. The overflow does not happen anymore on Firefox Beta for Android, but there is still some weird extra space to the right of the element occuring, despite the img element having the proper sizes in the Inspector. Will check further tomorrow.

Comment 8

[Daniel Holbert [:dholbert]]

I think the original issue is actually fixed now -- I'll track a fix range.

The attached testcase doesn't work anymore since its placeholder image hosting service has disappeared; but if I put in my own placeholder image, I see good results.

I'll tidy things up here and close this out. But in the meantime, please file a new bug for the issue you're seeing and please CC or needinfo me to take a look (no promises on a fix, but I'm curious to see what's going on). Thanks!

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: 700x393 placeholder image for use in testcase

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (same as reporter's testcase, but now with bugzilla-hosted image files)

Comment 11

[Daniel Holbert [:dholbert]]

Looks like our behavior here changed twice.

When this bug was filed, each image forced itself to have a container with the image's intrinsic width (700px).

Then we changed (for the better) in this commit range, I suspect due to bug 1909761:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e8cf043939ae46485e1f683456c399b124b688cd&tochange=7fa1ed101e2409de766a42d4f784acfb45a95fa2

In builds immediately after that^ fix range, there's still blank space between the images, but that space squishes to fit the available space (based on the viewport size). But if your viewport is sufficiently large, then the images reserve 700px of horizontal space.

Then we changed again in this commit range, due to bug 1926015:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a4434b7aabdac9a19413cbeff360c874bb138110&tochange=7df628ab162c87151d7783027905fa7950da76ef

After that point, we match Chrome on the testcase and don't show any space between the images here.

--> Seems to have been fixed by bug 1926015.