Subgrid item's size can be different depend on its container's `overflow` property value
Categories
(Core :: Layout: Grid, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: TYLin, Assigned: TYLin)
References
Details
Attachments
(5 files)
While working on bug 1527539, I'm playing with subgrid with overflow property, but I found that the subgrid item's size can be different depend on its container's overflow property value.
Please see the attached testcase. I expect the auto sized <div class="subitem"></div> covering the entire area of the subgrid, and the three cases should have the same rendering.
Also, the second case (overflow:auto) doesn't stable. On my linux machine, the subgrid container doesn't have any scrollbars, but after opening devtools, the scrollbars show. On my Mac, the behavior is just the opposite.
Mats or Daniel, does the above expectation sound correct to you?
|
||
Comment 1•4 years ago
|
||
Yeah, something seems wrong here. We're probably not properly accounting for the borderpadding when computing the size of the grid area that's available to the innermost item (the child of the subgrid).
Note that in this testcase's examples, each inner item's size is determined by its default align-self:stretch; justify-self:stretch behavior, which make it grow to fill its grid area, since it has width and height of auto. If you set it to align-self:start or end, then it will instead size to its content (which is empty).
So, the subitem here is just showing how large we're thinking the grid area is.
(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #0)
Also, the second case (
overflow:auto) doesn't stable. On my linux machine, the subgrid container doesn't have any scrollbars, but after opening devtools, the scrollbars show. On my Mac, the behavior is just the opposite.
If I resize my window horizontally, the scrollbars alternately disappear & show up again with each "tick". I think opening/closing devtools is just another way of triggering this same behavior (forcing an incremental reflow).
|
|
||
Comment 2•4 years ago
•
|
||
Here's another testcase with 4 grid items in each subgrid, snapped to each corner with align/justify-self.
In the bottom testcase, the end-edge items are positioned out of view for some reason and get clipped (which may indicate that we're making the grid area too large).
|
Assignee | |
Comment 3•4 years ago
|
||
Thank you Daniel! I think I know what went wrong.
|
|
Assignee | |
Comment 4•4 years ago
|
||
The helper is going to be used in a later part.
I don't add the physical version ComputedPhysicalBorder() deliberately
because I don't want to promote the usage of physical coordinate.
|
|
Assignee | |
Comment 5•4 years ago
|
||
SizeComputationInput's logical margin and border&padding getters accept
arbitrary writing mode, so we can operate on cbWM directly without
using physical coordinates.
This patch is a preparation of the next part, and it shouldn't change
the behavior.
Depends on D114544
|
|
Assignee | |
Comment 6•4 years ago
|
||
When aGridFrame.mFrame is a scroll frame, the inner scrolled frame
subgridFrame only has padding, but no margin nor border. We should add
margin and border on the outer scroll frame to mMarginBorderPadding so
that the grid area of the subgrid is computed correctly.
Depends on D114545
|
||
Comment 9•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4c5d0ee7fbe4
https://hg.mozilla.org/mozilla-central/rev/d90d530ebb5d
https://hg.mozilla.org/mozilla-central/rev/02aeefba2bce
Description
•