This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
For flex items with an aspect-ratio, the expectation is that the stretched
cross-sizes can be transferred to the main axis, affecting their intrinsic
inline-size contribution to the flex container's intrinsic inline-size.
Add `aspect-ratio-intrinsic-size-008.html` (adapted from 003.html) to test a
flex item with border and padding since the existing tests do not cover this.
Differential Revision: https://phabricator.services.mozilla.com/D222050
Currently, only the grid container needs the containing block size to resolve
the transferred min and max sizes for `repeat()` function in
`nsGridContainerFrame::ComputeIntrinsicISize()`.
This patch is a preparation for Bug 1865438. `mContainingBlockSize` will be used
there, so it does not change any behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D221333
Rename `mPercentageBasis` to `mPercentageBasisForChildren` to clarify that the
percentage basis is intended for resolving the percentage sizes for child
frames.
Differential Revision: https://phabricator.services.mozilla.com/D221332
In the old logic, the table's content inline size is stored in the `min`
variable, and passed into `AddIntrinsicSizeOffset()` to account for margin,
border, and padding.
We don't seem to have test coverage for this behavior, so I added some WPTs in
the next part.
This patch shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D221236
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
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
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
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
The underlying helper `IntrinsicForAxis()` already accepts an optional
percentage basis. This patch adds the same percentage basis argument to
`IntrinsicForContainer()`, allowing future callers to use it without needing to
convert to `IntrinsicForAxis()`.
This patch is a preparation for bug 1909761.
Differential Revision: https://phabricator.services.mozilla.com/D217792
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
Both '-webkit-fill-available' and 'stretch' are equivalent to '-moz-available'
at this point in the patch series, and both are off-by-default, because
actually supporting them would require that we add special logic to handle them
as block-axis sizes (which I'll do in a separate bug).
Differential Revision: https://phabricator.services.mozilla.com/D217687
This patch is intended to be mechanical, just adding the new keyword as an
alias for the existing behavior, basically.
In a later bug, 'stretch' will gain additional capabilities before we enable
the pref. After that, I intend to ultimately make '-moz-available' an alias of
'stretch', assuming that doing so is web-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D217686
This patch doesn't change behavior.
The '-moz-available' keyword is our closest equivalent to the CSS 'stretch'
keyword, *specifically* for the inline axis (since we currently nerf
'-moz-available' to behave like the initial value in the block axis). Hence, it
makes sense to say that the '-moz-available' keyword "Behaves Like Stretch On
Inline Axis".
By abstracting the existing behavior behind this helper-function, we can
start implementing the actual 'stretch' value in terms of this existing
behavior, in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D217685
A potentially better approach could be to call FrameNeedsReflow from
nsBCTableCellFrame::SetBorderWidth... But it seems that might
over-invalidate quite a lot when recalculating borders, since it seems
we reset the relevant ones and then accumulate directly on the frame.
If that seems like a better approach, happy to give that a try. This
should be less risky for performance changes in general tho.
Differential Revision: https://phabricator.services.mozilla.com/D216409
`ComputeISizeValue()` used to take `StyleSizeOverrides`, but
This patch reflects the fact that intrinsic inline size value such as
'min-content', 'max-content', etc. can be resolved via a definite block size and
a preferred aspect-ratio.
For the callers in `nsIFrame::ComputeSize()` and
`nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`, we can pass the
`styleBSize` and `aspectRatio` that have considered the size overrides.
Also, simplify `ComputeISizeValueFromAspectRatio()` so that it can be reused in
other places. We'll adapt more callers in the next part. Note that the `aFlags`
parameter is unused, so it is removed.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215294
Every time we recompute border collapsed table borders, we discard previously
computed values. This is done to avoid statefulness bugs, like Bug 1871609.
When a table-edge cell is modified, the border computation needs to extend
to cover all cells adjacent to that edge, to determine which cell contributes
to the maximum border-width.
Also, rename the use of X/Y usage to Col/Row to reduce potential confusion.
Differential Revision: https://phabricator.services.mozilla.com/D213793
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
