I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
We can correctly append elements into a multicol container even when they have
column-span descendants, so remove the assertion to allow this operation.
The WPT added in this patch triggers the assertion in the old code.
Differential Revision: https://phabricator.services.mozilla.com/D281580
This removes the implementation of nsHTMLButtonControlFrame, instead
reusing nsBlockFrame + align-content (or the relevant display type for
flex / grid / columns / etc).
This matches what Blink does and, for the most part, it is trivial.
It requires moving some special cases around, and override inline flow
display, tho so that buttons don't suddenly start fragmenting in the
inline axis.
It adds a tiny fix for a writing-mode mismatch in
nsBlockFrame::AlignContent(), covered by
layout/reftests/writing-mode/1138356-1-button-contents-alignment.html
containing-block-change-button tests are tweaked to avoid overflowing
the 600px viewport from WPT reftests causing scrollbar fuzziness.
contain-layout-baseline-005.html removes the <select> element just like
https://chromium-review.googlesource.com/c/chromium/src/+/5479489
removed the <button>s, since they align the same now, added a test for
that.
Differential Revision: https://phabricator.services.mozilla.com/D257149
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
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
`ColumnSetWrapperFrame` inherits from `nsBlockFrame`, which already has member
variables to cache the intrinsic inline sizes. Let's use it.
Differential Revision: https://phabricator.services.mozilla.com/D217791
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
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Add multicol-width-004.html and multicol-width-005.html to test "width:
min-content" and "width: max-content" with column-span:all children.
There's no size containment in these tests.
Note it may be worth to reuse nsBlockFrame's mCachedMinISize and
mCachedPrefISize to cache intrinsic size for ColumnSetWrapperFrame, but
this can be done separately.
Differential Revision: https://phabricator.services.mozilla.com/D29616
Sylvestre Ledru