This patch refactors the logic for propagating overflow to the viewport,
fixing various issues:
- Now we won't propagate from the root element if it has no box. Note
the fix isn't observable in Servo because we lack scrollbars.
- If the first `<body>` element has no box, we won't keep searching for
other `<body>` elements. This deviates from the spec, but aligns us with
other browsers.
- We won't propagate from the `<body>` if it has no box. We were already
handling `display: none` but not `display: contents`. This deviates from
the spec, but aligns us with other browsers.
Also, when we flag the root or `<body>` as having propagated `overflow`
to the viewport, we retrieve the `LayoutBoxBase`. Therefore, now we get
the computed style from the `LayoutBoxBase` in a single operation,
instead of first retrieving the style from the DOM element and then
getting the `LayoutBoxBase` from the box.
Testing: Adding more tests. We were only failing one of them, but it's
hard to test the fixes given that we don't show scrollbars. The tests
that were already passing are useful too, e.g. Firefox fails one of
them.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
They only had the writing mode, now they will have the entire computed
style.
This is needed for #39230.
Testing: Not needed, no behavior change
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
A LayoutBox typically has one LayoutBoxBase, or none in the case of
`LayoutBox::DisplayContents`. However, `LayoutBox::InlineLevel` can
contain multiple inline items, each one with its base. But since things
like the style or the fragment flags should be the same for all of them,
getting the first base is sometimes enough.
Testing: not needed, no change in behavior.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
The `overflow-*` values of either the root element or the `<body>` get
propagated to the viewport. However, we were missing this part:
> The element from which the value is propagated must then have a used
`overflow` value of `visible`.
See https://drafts.csswg.org/css-overflow/#overflow-propagation
Testing:
- `css/cssom-view/scrolling-quirks-vs-nonquirks.html`
- `css/css-overflow/overflow-body-propagation-007.html`
- `css/css-overflow/overflow-body-propagation-008.html`
- `css/css-overflow/overflow-body-propagation-009.html`
- `css/css-overflow/scrollable-overflow-with-nested-elements-001.html`
- `css/css-overflow/scrollable-overflow-with-nested-elements-002.html`
- `css/css-overflow/scrollable-overflow-with-nested-elements-003.html`
- `css/css-overflow/scrollable-overflow-with-nested-elements-004.html`
- `css/css-overflow/scrollbar-gutter-scroll-into-view.html`
Failures:
- `css/css-overflow/overflow-body-propagation-010.html`
Failing because of missing support for `contain: paint`.
- `css/css-overflow/scrollable-overflow-with-nested-elements-005.html`
Failing because of wrong `data-expected-height`, but correct
`data-expected-scroll-height` which is core of this PR.
`data-expected-height` can be dealt separately.
Fixes: #38248
---------
Signed-off-by: Shubham Gupta <shubham13297@gmail.com>
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Use `ServoThreadSafeLayoutNode` in more places in layout rather than
`ServoLayoutNode`. The former is meant to be used during layout, but
layout 2020 was written against the latter. In general, this reduces the
amount of conversion to the thread-safe version in many places in
layout.
In addition, an unused iterator from the `script` crate
`ServoThreadSafeLayoutNodeChildrenIterator` is replaced with the child
iterator from `layout`. The `layout` version must be directly in
`script` now as it uses the dangerous variants of `next_sibling` and
`first_child`, which allow encapsulating the unsafe bits into one
module.
This will ultimately be useful for storing the layout data of
pseudo-element children of pseudo-elements properly.
Testing: This should not change any behavior and thus is covered by
existing tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Moves `Size`, `SizeConstraint`, `Sizes` and `LazySizeData`.
Testing: Not needed, no change in behavior.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
We were instead stretching to the containing block, which implied that
the behaviors of a `stretch` size and `stretch` alignment weren't
consistent.
As resolved by the CSSWG, the behavior will now be:
- If the cross size of the line is known, stretch to the line.
- Otherwise, stretch to the containing block.
See https://github.com/w3c/csswg-drafts/issues/11784
This aligns us with Blink, which has already shipped this new behavior.
Testing: Improves existing WPT and adds a new test.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
When stretching the cross size of a flex item to its flex line, we were
computing the stretch size by subtracting padding, border and margin
from the line size. However, this could result in a negative amount for
the content-box cross size. Therefore, this floors it by zero.
Testing: Adding new tests
Fixes: #38517
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
This performs various refactorings:
- Turns `content_size` into `content_block_size`, losing the inline
component, since it was the same as `containing_block_inline_size`.
- Merges `containing_block_inline_size` and
`containing_block_block_size` into `containing_block_size`.
- Removes `has_child_which_depends_on_block_constraints` since this
information should already be in `depends_on_block_constraints`.
- `FlexItem::layout()` is no longer responsible for trying to reuse the
previous result. Therefore it no longer returns an `Option`, and no
longer accepts the previous result as a parameter.
- `FlexItemLayoutResult::compatible_with_containing_block_size()` is
removed, and a simplified version is inlined into the relevant caller of
`FlexItem::layout()`.
Testing: Not needed (no change in behavior)
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
The logic was wrong, sometimes we weren't setting it to true on flex
containers that needed it, and then as a workaround we were setting it
to to true on flex items that didn't need it.
For example, this testcase had 5 cache misses when stretching the items,
now we will avoid laying them out again:
```html
<div style="display: flex">
<div></div> <div></div> <div></div> <div></div> <div></div>
</div>
```
Also, the workaround wasn't always working, e.g. it failed to stretch
the green element here:
```html
<div style="display: flex; min-height: 200px">
<div>
<div style="display: flex; height: 100%; background-color: red">
<div style="width: 200px; background-color: green;"></div>
</div>
</div>
</div>
```
Testing: Adding new test
Fixes: #38023
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
This change adds some minor optimizations and bugfix for non-functional
details with seperated commits:
- fix the omission that stop use `Rayon` in single-thread mode
- add trace for incremental box tree construction
- fix the bug that failed to skip reflow entirely when there is no need
for `restyle` and a fragment tree has already been built.
- add trace for stylist preparation during reflow. In certain scenarios,
this phase might take up a significant amount of time, such as when
there are a large number of shadow trees.
Testing: This should not change observable behavior and is thus covered
by existing WPT tests.
---------
Signed-off-by: sharpshooter_pt <ibluegalaxy_taoj@163.com>
When a style change does not chang the structure of the box tree, it is
possible to skip box tree rebuilding for an element. This change adds
support for reusing old box trees when no element has that type of
damage. In order to make this happen, there needs to be a type of
"empty" `LayoutDamage` that just indicates that a fragment tree layout
is necessary.
This is the first step toward incremental fragment tree layout.
Testing: This should not change observable behavior and thus is covered
by
existing WPT tests. Performance numbers to follow.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Laying out a flex item will now use the same logic regardless of whether
it's replaced or not.
This reduces the amount of code, and should have no observable effect.
Testing: Unneeded (no behavior change)
This part of #37942
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Clearance only applies to block-level boxes, so it was unnecessary to
require it as a parameter. Instead, in block layout we can set it using
the new `.with_clearance()` method.
Testing: Unnecessary (no behavior change)
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
It was very easy to forget about using `.with_specific_layout_info()` to
set the specific layout info, so it's better to make it a parameter.
In fact this already happened in the past: #36993 fixed the missing
specific layout info for flex items.
This patch fixes it for floats and atomic inlines. It also propagates it
in other cases where not doing so was not a big deal because the
specific layout info was None, but that was a fragile assumption.
Testing: Various WPT improvements
Fixes: #37898
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
The logic for laying out block-level replaced elements wasn't taking
floats into account when resolving a `stretch` inline size. By handling
them with the same logic as non-replaced elements, we fix that problem,
and reduce the amount of code.
Testing: Adding new tests
Fixes: #37861
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Layout: Continue support incremental box tree reconstruction for
flex&taffy level box
This change reuse the flex/taffy level box from old box slot if the box
slot is valid and there is no LayoutDamage to the element.
Testing: This should not change observable behavior and is thus covered
by existing WPT tests.
Signed-off-by: sharpshooter_pt <ibluegalaxy_taoj@163.com>
In layout, some parts of the code were still using parallel iterators
from Rayon even when single-thread layout was activated. This change
modifies those parts to use non-parallel iterators when
`LayoutContext::use_rayon` is not active.
Testing: It's very hard to make an automated test for this, but I've
manually
verified this by building with tracing and observing that layout runs
only on
a single thread now when loading https://servo.org.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
#37433 didn't handle intrinsic contributions. This patch computes the
correct SizeConstraint to be used as the ConstraintSpace's block size
when computing intrinsic inline sizes.
Testing: Adding new test
Fixes: #37478
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
`FlexContainer::layout()` was forcing `depends_on_block_constraints` to
true for `flex-direction: column`. However, it doesn't make sense to do
that only for `column` but not for `column-reverse`. Also no test is
complaining, so I'm just removing that logic.
Testing: no behavior change is intended, so just existing test coverage
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Text decorations have a special kind of propagation. Instead of
propating these during box tree construction, move propagation to
stacking context tree construction. This will allow for using a very
easy type of incremental layout when text decorations change. For
instance, when a link changes color during hovering over it, we can skip
all of box and fragment tree construction.
In addition, propagation works a bit better now and color and style
properly move down from their originating `Fragment`s.
This introduces three new failures, because now we are drawing the
text-decoration with the correct color in more places, which exposes an
issue we have with text-decorations not being drawn in relation to the
baseline (taking into account `vertical-align`).
Testing: There are tests for these changes.
Fixes#31736.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
`min_content_main_size_for_multiline_container` was initialized to an
outer size, but then it could be clamped by inner sizes.
This patch ensures that it's clamped by outer sizes, and refactors
`FlexItemBoxInlineContentSizesInfo`.
Testing: Covered by WPT
Fixes: #37008
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
When making last-minute changes to the repaint-only layout pass, damage
propagation was broken, meaning that full layout was always done. This
change fixes that, meaning that times in the `blaster.html` test case
now reflect those described in the original commit message from #36978.
In addition, some style repair is now fixed:
- `InlineFormattingContext`s now keep a `SharedInlineStyles` for the
root of the IFC
which is updated during style repair.
- `BlockFormattingContext`s now properly update their style.
These changes are verified by turning on repaint only layout for more
properties
in Stylo via servo/stylo#183.
Testing: Manual performance testing via `blaster.html`.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Fixes a regression from #36973, which didn't take into account that
stretching flex items affects their final block size when the cross axis
is the block axis.
Testing: Adding new test
Fixes: #37023
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Intrinsic sizing keywords weren't working correctly on the min and max
block sizes of a flex container, because we weren't setting the
`CacheableLayoutResult::content_block_size` to the right value. This
also ensures that `align-content` aligns within the final size of the
container.
Note it's not very clear what to do for single-line containers, they are
being discussed in https://github.com/w3c/csswg-drafts/issues/12123
Testing: Adding new WPT tests. There are still some failures, but most
subtests would fail without this change.
Fixes: #36981
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Before this patch it wasn't possibly to simultaneously support intrinsic
min/max sizes and content alignment in the block axis. For example,
block containers only support the former, and flex containers only the
latter.
The reason is that the final block size was decided by the parent
formatting context *after* performing layout, while content alignment is
performed *during* layout.
To address the problem, this introduces the struct `LazySize`, which
contains the data to resolve the final size, except for the intrinsic
size. Thus the parent formatting context can first create a `LazySize`,
then pass it to the child layout so that (if necessary) it can compute
the final size once the intrinsic one is known, and after layout the
parent formatting context uses it to actually size the child.
This PR just provides the functionality that will be used by follow-ups,
but at this point no layout is using the `LazySize` provided by the
parent, so there shouldn't be any behavior change yet.
Testing: Unnecessary (no behavior change)
This is part of #36981 and #36982
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
We should propagate specified info for flex items. This will prevent the
loss of it for boxes that have this info (e.g. table or grid).
Testing: Adding new WPT tests
---------
Signed-off-by: stevennovaryo <steven.novaryo@gmail.com>
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This change adds the simplest kind of incremental layout. When Servo
detects that all style changes only require a repaint, only run stacking
context tree and WebRender display list generation. This means that
these kind of restyles do not need a re-layout. Instead, the existing
box and fragment trees will be used and the styles of damaged nodes will
be updated in their box and fragment tree nodes.
This requires a new style repair DOM traversal for nodes that have had
their style damaged. In addition, careful accounting of all the places
where we store style must happen in order ot update those styles.
Testing: This is covered by existing WPT tests as it should not change
observable behavior.
We have created a test case which shows a 50% speedup when run
in Servo, even though there still a long way to go to match the speed
of other browsers:
https://gist.github.com/mrobinson/44ec87d028c0198917a7715a06dd98a0
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
`TextRun`s use their parent style to render. Previously, these styles
were cloned and stored directly in the box tree `TextRun` and resulting
`TextFragment`s. This presents a problem for incremental layout.
Wrapping the style in another layer of shared ownership and mutability
will allow updating all `TextFragment`s during repaint-only incremental
layout by simply updating the box tree styles of the original text
parents.
This adds a new set of borrows when accessing text styles, but also
makes it so that during box tree block construction
`InlineFormattingContext`s are created lazily and now
`InlineFormattingContextBuilder::finish` consumes the builder, making
the API make a bit more sense. This should also improve performance of
box tree block construction slightly.
Testing: This should not change observable behavior and thus is covered
by existing WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This makes it so that layout is no longer generic on the node type,
depending directly on `script`'s `ServoLayoutNode`. In addition to
greatly simplifying layout, this is necessary because incremental layout
needs to be able to create pseudo-element styles without having a handle
on the original `impl LayoutNode`. We feel this is a reasonable
tradeoff.
Testing: No functional changes, so covered by existing WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
`PositioningContext` held two vectors, one inside an `Option`, to
differentiate between the version used for a containing block for all
descendants (including `position: absolute` and `position: fixed`) or
only for `position: absolute` descendants. This distinction was really
hard to reason about and required a lot of bookkeeping about what kind
of `PositioningContext` a layout box's parent expected. In addition, it
led to a lot of mistakes.
This change simplifies things so that `PositioningContext` only holds a
single vector. When it comes time to lay out hoisted absolutely
positioned
fragments, the code then:
- lays out all of them (in the case of a `PositioningContext` for all
descendants), or
- only lays out the `position: absolute` descendants and preserves the
`position: fixed` descendants (in the case the `PositioningContext`
is only for `position: absolute`.), or
- lays out none of them if the `PositioningContext` was created for
box that did not establish a containing block for absolutes.
It's possible that this way of dealing with hoisted absolutes is a bit
less efficient, but, the number of these descendants is typically quite
small, so it should not be significant. In addition, this decreases the
size in memory of all `PositioningContexts` which are created in more
situations as time goes on.
Testing: There is a new WPT test with this change.
Fixes: #36696.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
As per
[w3.org/TR/filter-effects-1#FilterProperty](https://www.w3.org/TR/filter-effects-1/#FilterProperty),
`filter` shouldn't make the root element establish a containing block
for absolute and fixed positioned descendants. `will-change: filter` has
matching behavior.
This PR adds a check for if we are the root element before establishing
such a block.
To know if we are the root element, we look at the `FragmentFlags`
passed in. Previously for our function, these were dummy flags, always
constructed as empty. Thus, this PR also makes sure the correct
FragmentFlags are passed down the chain to the function
`establishes_containing_block_for_all_descendants`.
Testing:
- `/css/filter-effects/filtered-html-is-not-container.html` now passes
- `/css/css-will-change/will-change-fixedpos-cb-003.html` now passes
- Manual tests are working
Fixes: #35391
---------
Signed-off-by: haval0 <56519858+haval0@users.noreply.github.com>
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Now that legacy layout has been removed, the name `layout_2020` doesn't
make much sense any longer, also it's 2025 now for better or worse. The
split between the "layout thread" and "layout" also doesn't make as much
sense since layout doesn't run on it's own thread. There's a possibility
that it will in the future, but that should be something that the user
of the crate controls rather than layout iself.
This is part of the larger layout interface cleanup and optimization
that
@Looriool and I are doing.
Testing: Covered by existing tests as this is just code movement.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
