The pref was enabled by default in bug 2002115 and shipped in Firefox 151. Since
it has been two releases, we can remove it to simplify the code path.
Differential Revision: https://phabricator.services.mozilla.com/D302349
Same implementation over two different compilation units advocate for
promotion to a method.
This also prevents conflicts in the generalization of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D298968
Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
Moved ReflowInput::BreakType enumuration outside ReflowInput class to mozilla::BreakType, and refactored the functions using it to reflect the change.
Differential Revision: https://phabricator.services.mozilla.com/D298034
This renames the measuring reflow flag to use "fragmentainer" terminology,
making it applicable to both multicol and printing contexts. This doesn't change
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D284549
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
Similar to previous patch, percentage column-gap should be resolved against
`availableContentISize`, which is the content-box inline-size of
`ColumnSetWrapperFrame`.
Quote the spec text https://drafts.csswg.org/css-align/#gap-percent,
```
gap always resolves percentages against the corresponding size of the content
box of the element.
```
Differential Revision: https://phabricator.services.mozilla.com/D280192
TL;DR: When computing the inline-size of each column (the `-moz-column-content`
anonymous block under `nsColumnSetFrame`) in `ChooseColumnStrategy()`, it is
sufficient to use the available inline-size that `ColumnSetWrapperFrame` passes
down. Considering the computed inline-size can be wrong in an edge case
described below.
Details:
The used inline-size of `nsColumnSetFrame` is computed from the union of
every *non-empty* columns [1]. A column content is considered empty if it
contains only overflow containers. For example, a very short absolute containing
block (absCB) may contain a tall abspos element that fragments over several
columns. If the absCB fits in the first column, its remaining continuations
become overflow containers (with zero block-size) holding the rest of the tall
abspos continuations. In that case, an `nsColumnSetFrame` with two columns ends
up with a final used inline-size of only one column wide, because the second
column is considered empty.
Now suppose this `nsColumnSetFrame` is itself inside a nested multicol
structure, and needs to be fragmented. When reflowing the `nsColumnSetFrame`
continuations, we override their *computed* inline-size with their
prev-continuation's inline-size [2]. Thus, its computed inline-size is also one
column wide, which by itself is fine. However, if we use that narrower
inline-size to compute the column width, each column content's width becomes
half a column wide, which is wrong.
Instead, it is sufficient to use just the available inline-size passed down by
`ColumnSetWrapperFrame` to determine the used column width.
[1] https://searchfox.org/firefox-main/rev/897ad323744cc6d3afe39845cfb94b015e9f65a0/layout/generic/nsColumnSetFrame.cpp#760,923
[2] https://searchfox.org/firefox-main/rev/897ad323744cc6d3afe39845cfb94b015e9f65a0/layout/generic/nsContainerFrame.cpp#906-912
Differential Revision: https://phabricator.services.mozilla.com/D280191
This patch implements the fragmentainer-aware positioning for abspos elements in
multicol. High-level changes include:
- Store abspos element's unfragmented position in
`nsIFrame::UnfragmentedPositionProperty`.
- Add a measuring reflow phase in `nsColumnSetFrame` to compute abspos element's
unfragmented position.
- Track cumulative containing block size across fragmentainer continuations.
- Adjust positioning logic with UnfragmentedPositionProperty().
A similar support for printing scenario is tracked in Bug 2009647.
Differential Revision: https://phabricator.services.mozilla.com/D276582
This reverts commit 2cead8c0d6.
Revert "Bug 1994346 - Adjust existing test expectations. r=layout-reviewers,dshin,dholbert"
This reverts commit 527178ed44.
Revert "Bug 1994346 - Push abspos first-in-flow to next absCB continuation if it doesn't fit. r=layout-reviewers,dholbert,dshin"
This reverts commit 8ccca3d28a.
This patch implements the fragmentainer-aware positioning for abspos elements in
multicol. High-level changes include:
- Store abspos element's unfragmented position in
`nsIFrame::UnfragmentedPositionProperty`.
- Add a measuring reflow phase in `nsColumnSetFrame` to compute abspos element's
unfragmented position.
- Track cumulative containing block size across fragmentainer continuations.
- Adjust positioning logic with UnfragmentedPositionProperty().
A similar support for printing scenario is tracked in Bug 2009647.
Differential Revision: https://phabricator.services.mozilla.com/D276582
No need to reposition views during layout and so on, now that we don't
use views for either popups nor subdocuments.
No need for nsView to have parent / sibling / children either.
Differential Revision: https://phabricator.services.mozilla.com/D271205
No behavior change, but this saves some per-child work and conceptually
is the right thing to do. HidesContent() is non-trivial.
Add an assertion to make sure we don't enter BuildDisplayListForChild
at all if content is hidden.
I audited all the callers, and the ones I didn't touch can't have
content-visibility (things like the viewport / pages / etc).
Differential Revision: https://phabricator.services.mozilla.com/D265956
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
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
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
Also, rewrite GetInlineDir() and GetBlockDir() to remove bit operations for
computing the InlineDir and BlockDir enum variants.
Differential Revision: https://phabricator.services.mozilla.com/D208176
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 bug occurs because some abspos children are split, but not being reflowed
again in the last column balancing reflow where the available block-size of the
last column might be unconstrained.
This patch makes the callers utilizing `ReflowInput::ShouldReflowAllKids()`
always reflow in the last column balancing reflow to ensure the correctness of
the layout.
Note: the `mIsInLastColumnBalancingReflow` flag is inheriting from parent to
child reflow input, but it will stop at the nested `nsColumnSetFrame` because
the nested one will create its own `ReflowConfig::mIsLastBalancingReflow` and
assign that flag when creating the reflow input for the children.
Differential Revision: https://phabricator.services.mozilla.com/D195945
In bug 1844755, a bunch of the time is spent allocating initial values.
There used to be more document-dependent initial values before
bug 1834487, but now that's only about default-font and direction.
This improves the situation by sharing initial structs that don't depend
on the document.
Differential Revision: https://phabricator.services.mozilla.com/D184256
Make the computed value of border-like properties app units (which is
effectively what happens in Gecko already), and clamp at computed value
time.
Differential Revision: https://phabricator.services.mozilla.com/D179481
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
A top-level multicol in a paginated context can be fragmented. We should use the
same logic to set the `mIsTopOfPage` bit as if the multicol is a nested one.
WARNING: loading the testcase without this patch can trap Firefox in an infinite
loop.
Differential Revision: https://phabricator.services.mozilla.com/D177578
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
Ting-Yu Lin