content-based 'flex-basis' produces a width of 0, in case where descendant with aspect ratio and resolvable percent height should prop it up
Categories
(Core :: Layout: Flexbox, defect)
Tracking
()
People
(Reporter: dholbert, Assigned: TYLin)
References
(Blocks 1 open bug)
Details
(Keywords: webcompat:platform-bug)
Attachments
(4 files)
[Filing this for https://github.com/webcompat/web-bugs/issues/97271 aka https://webcompat.com/issues/97271 ]
STR:
- Load attached testcase.
EXPECTED RESULTS:
You should see nested square borders with a solid-lime rectangle in the middle.
ACTUAL RESULTS:
No lime is visible; that rectangle is 0-width, as you can see from the collapsed black and orange borders.
This is apparently causing webcompat pain on reddit, as detailed in the webcompat.com report.
Firefox Nightly gives ACTUAL RESULTS.
Chrome gives EXPECTED RESULTS, which I think is correct here.
|
Reporter | |
Comment 1•4 years ago
|
||
|
|
Reporter | |
Comment 2•4 years ago
|
||
|
|
Reporter | |
Comment 3•4 years ago
•
|
||
Notes:
-
We render the reference case correctly (i.e. we give EXPECTED RESULTS there). Its markup only differs from the testcase in that it uses a definite
padding: 30pxinstead ofpadding: 10%. I think these two declarations are equivalent and are both definite, since the percent padding can be trivially resolved against the definitewidth:300pxof the parent. Hence, I think the testcase and reference case can be expected to render the same, and the fact that they don't is indicative of a Firefox bug. -
I have an explicit
flex-basis:contentin both attachments, but that's technically unnecessary - I just put it there for robustness. If you put some other non-content-dependent flex-basis there, e.g.flex-basis:0orflex-basis:20px, then Firefox and Chrome agree on the rendering (and use the provided flex-basis value as the flex item's width).
|
Assignee | |
Comment 4•4 years ago
|
||
I think this might be bug 1231059 that we wrongly use the block-size to resolve the percentage padding in order to compute the box-sizing:border-box adjustment in [1] or [2]. The evidence is that If you set height:300px to <body> in the testcase 1, it renders like the reference case.
If we want to fix this, it might be worth investigating bug 1363918 first.
[1] https://searchfox.org/mozilla-central/rev/253ae246f642fe9619597f44de3b087f94e45a2d/layout/base/nsLayoutUtils.cpp#4401-4413
[2] https://searchfox.org/mozilla-central/rev/253ae246f642fe9619597f44de3b087f94e45a2d/layout/base/nsLayoutUtils.cpp#4442-4458
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 5•4 years ago
•
|
||
I'm pretty sure https://webcompat.com/issues/105402 is a version of this bug, too.
Here's ksenia's reduced data-URI testcase from there:
data:text/html,<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><style>.photogallery-wrapper {height: 0;padding-top: 56.25%;position: relative;overflow: hidden;}.photogallery-swiper {position: absolute;top: 0;left: 0;width: 100%;height: 100%;background: rgb(0, 0, 0) none repeat scroll 0% 0%;}.swiper-wrapper {position: relative;width: 100%;height: 100%;display: flex;}.swiper-slide {width: 100%;height: 100%;position: relative;display: flex;justify-content: center;}.swiper-slide picture {height: 100%;display: flex;align-items: center;}.swiper-slide img {max-height: 100%;width: 100%;display: block;}</style></head><body><div class="photogallery-wrapper"><div class="photogallery-swiper"><div class="swiper-wrapper"><div class="swiper-slide"><picture><img data-src="/cropgd/160x232/dl/img/2022/06/04/1654304456887_larepubblica.jpeg"alt="Prima pagina de %E2%80%9Cla Repubblica%E2%80%9D"src="https://www.rainews.it/cropgd/160x232/dl/img/2022/06/04/1654304456887_larepubblica.jpeg"></picture></div></div></div></div></body></html>
As in comment 3: if I edit this data-URI testcase to use a pixel-valued padding on .photogallery-wrapper (instead of padding-top: 56.25%;), I end up with expected results. And similarly, if I add a pixel-valued height to that element, we seem to resolve descendant-percentages against that height instead of against the size of the padding box. (We should use the padding-box as the containing block for abspos descendants, per https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block )
I'll post a further-reduced version of ksenia's testcase as an attachment.
|
|
Reporter | |
Comment 6•4 years ago
|
||
Here's my further-reduced version of ksenia's testcase.
Firefox renders no lime here.
"Expected results" are for lime to be visible, and for the lime area (and its teal border) to occupy approximately half of its pink-bordered parent box's width.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 7•2 years ago
|
||
The two testcases are adapted from Daniel Holbert's testcase 1 and 2 in the bug.
Both are fixed by bug 1909761.
|
||
Updated•2 years ago
|
|
||
Comment 10•2 years ago
|
||
| bugherder | ||
|
||
Updated•2 years ago
|
|
||
Updated•1 year ago
|
Reproducible on a 2024-09-01 Nightly build on Windows 10.
Issue is verified as fixed on Firefox 132.0b2 and Firefox Nightly 133.0a1 on Windows 10, Ubuntu 22, macOS 14.
Description
•