Incorrect calculation of the inline min/max content contribution in grid tracking algorithm when using aspect-ratio property in grid item
Categories
(Core :: Layout: Grid, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox87 | --- | fixed |
People
(Reporter: boris, Assigned: boris)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
When using aspect-ratio on grid items, we calculate the size of this grid correctly, but its grid tracking size doesn't take this aspect-ratio property into account.
e.g.
.grid-container {
display: grid;
grid-template-columns: auto;
width: max-content;
height: 100px;
gap: 1rem;
}
.grid-item {
aspect-ratio: 1/1;
height: 100px;
width: auto; // the final width should be 100px (= 100px * 1 / 1).
min-width: 0px;
}
<div class="grid-container">
<div class="grid-item">
<div style="width:50px; height:50px;"></div>
</div>
</div>
The max content contribution of this grid item should be 100px. However, the actual result is 50px because IntrinsicForAxis()
and AddIntrinsicSizeOffset()
don't use aspect-ratio to replace the min-content and max-content values. This is a follow-up bug of Bug 1646100 for Grid layout.
Besides, the usage of AspectRatio in IntrinsicForAxis()
should take box-sizing into account. We always use content-box for now, in all cases. This is not correct. This is a follow-up bug for Bug 1683424.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
This is simliar with the previous patch, but we use
min-content/max-content for the inner div (i.e. child frame).
Perhaps we could remove the simliar implementation from
ComputeISizeValue(). However, I still keep it because it can avoid some
extra work when resolving {min|max}-content with aspect-ratio when
reflowing.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/373fe3a0806a
https://hg.mozilla.org/mozilla-central/rev/d5975841c326
Description
•