Bug 1277129 renamed `GridReflowState` to `GridReflowInput`, hence the renaming
of these parameters. This change also helps distinguish these variables from
`GridItemInfo::mState` and `TrackSize::mState`.
Differential Revision: https://phabricator.services.mozilla.com/D236290
`RepeatTrackSizingInput::InitFromStyle()` is called in
`nsGridContainerFrame::ComputeIntrinsicISize()`. When we compute a frame's
intrinsic inline size, its inline-size property should not affect the result.
Differential Revision: https://phabricator.services.mozilla.com/D235879
The pref layout.css.grid-flex-spanning-items-intrinsic-sizing.enabled is
expected to be removed once these regressions are fixed. This should be a good
compromise between maintaining the code from bug 1916849, and avoiding
breakage/extra backouts.
Differential Revision: https://phabricator.services.mozilla.com/D235089
Per the CSS Align specification, 'space-between', 'space-around', and
'space-evenly' should use a "safe" fallback alignment when overflow occurs. This
patch implements that behavior, renames the function for clarity, and removes
unused parameters.
Differential Revision: https://phabricator.services.mozilla.com/D234755
This has a couple unfortunate parts to its implementation. In particular, the
adjustment to ShouldApplyAutoMinSize are difficult to explain other than that
function doesn't actually calculate if the minimum contribution of an item is
content-based, but rather checks if the caller should also call MinSize or not.
Part of this calculation includes checking the min-size-auto of the item, but
some are just matching checks for special cases in MinSize.
This could be optimized, and should definitely be refactored to simplify how
all of this is computed.
This still doesn't quite correctly handle all cases for items spanning flex
tracks and tracks with a definite length, but that case is already not handled
correctly so this won't introduce any regressions for that case unless the
expected result is that such an item will have an intrinsic size of zero. In
that case, simply not calculating anything would accidentally be the correct
value, and this new calculation may or may not produce that result.
Differential Revision: https://phabricator.services.mozilla.com/D230829
Whether not this is actually useful to store separately is debatable.
While we will need to iterate spans to recalculate this in step 3, we
already need to iterate the tracks multiple times for step 3 so this
doesn't affect the complexity of the operation and this iteration is
relatively cheap.
This data was stored in an auto-array. This means that we only allocate
when the max span is large, but this means we either would do a larger
allocation before, or do more iterations now. At least now, we don't
allocate a big array for a single span, and the complexity of the
iteration is linear in the dimensions of the number of total spans and
the number of tracks in all spans combined, multiplied together. This
is the same complexity of each call to GrowSizeForSpanningItems, and so
is already the complexity of step 3 as a whole.
Differential Revision: https://phabricator.services.mozilla.com/D230438
Ideally, `BehavesLikeInitialValue()` should be defined via
`IMPL_BEHAVES_LIKE_SIZE_METHODS` macro in ServoStyleConstsInlines.h. However, it
accepts `LogicalAxis`, which is defined in `WritingModes.h`. Therefore, we have
to implement it in `WritingModes.h`.
Differential Revision: https://phabricator.services.mozilla.com/D230064
This avoids returning wrong intrinsic values with different calls into
intrinsic size computation, which is wrong by definition.
We shouldn't be wallpapering over it by clearing intrinsic sizes
mid-layout as the original patch was doing.
Differential Revision: https://phabricator.services.mozilla.com/D229621
This avoids returning wrong intrinsic values with different calls into
intrinsic size computation, which is wrong by definition.
We shouldn't be wallpapering over it by clearing intrinsic sizes
mid-layout as the original patch was doing.
Differential Revision: https://phabricator.services.mozilla.com/D229621
This currently does not actually affect anything, as we do not do intrinsic
sizing for grid items that span multiple tracks if any of those tracks are
flexible anyway.
This is in preparation to do intrinsic sizing for those items in Bug 1916849.
Differential Revision: https://phabricator.services.mozilla.com/D229189
For Grid Layout Algorithm, the difference between level 1 & 2 is just section
number. There is no additional top level steps in level 2.
Differential Revision: https://phabricator.services.mozilla.com/D227419
`CalculateTrackSizes()` is used only once, while `CalculateTrackSizesForAxis()`
is used more extensively. Let's just expand `CalculateTrackSizes()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D227300
We rely on the min/max sizes in the RepeatTrackSizingInput to determine
how many auto-repeat items we can place, so we have to make sure we take
aspect-ratio into account. So if we have aspect-ratio, we need to take
it into account and use the ratio-determining size to compute the
transferred min/max/preferred size.
However, we don't have the information of containing block now, and
we will fix the case if the ratio determining size has percentage in the
following patch.
Differential Revision: https://phabricator.services.mozilla.com/D195199
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This was already happening correctly when placing grid items, but it was not
implemented correctly when measuring the overal grid size.
Ideally, MaxSizingFor or some kind of replacement could do this kind of check
already. If you don't want to fiddle around with sizing functions then you
probably want to perform this check every time, and if you really need the
max sizing function directly you can just get it with SizingFor.
Differential Revision: https://phabricator.services.mozilla.com/D220196
