Previously, layout was handling scrollable overflow and srolling area
calculation separately, only excluding the "unreachable scrollable
overflow region" at the last step. In addition, `position: absolute` was
not included in scrollable overflow calculation.
This change combines the two concepts into a single scrollable overflow
calculation and starts taking into account `position: absolute`.
Finally, `BoxFragment::scrollable_overflow_for_parent` is converted to
use early returns which reduces the amount of indentation.
Fixes#35928.
Fixes#37204.
Testing: This causes some WPT test to pass, but also two to start
failing:
- `/css/css-masking/clip-path/clip-path-fixed-scroll.html`: This seems
to fail
because script is scrolling past the boundaries of the document. This is
a
failure that was uncovered by the fixed element now being added to the
page's scroll area.
- `/css/css-overflow/overflow-outside-padding.html`: One test has
started to fail
here because now the absolutely positioned element is included in the
scroll area,
and I think there is an issue with how we are placing RTL items with
negative margins.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This is a minor cleanup that simplifies the construct of
`StackingContextTree`. The two arguments removed are derived from the
`FragmentTree` which is already passed as an argument.
Testing: This should not change behavior and is thus covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Instead of computing scrollable overflow while constructing the fragment
tree, we will now do it later. In the future this will also allow to
only recalculate the overflow without rebuilding the tree when transform
properties change, but that's left for a follow-up.
Stylo PR: https://github.com/servo/stylo/pull/194
Testing: One test is now passing (more investigation is needed), but
otherwise this isn't expected to have any effect.
Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
When the the current transformation matrix of a box isn't invertible,
the box and its content shouldn't be displayed.
However, the logic was broken:
- It was only checking the `transform` property, but not individual
transform properties like `scale`.
- It was treating matrices with m₁₁=0 or m₂₂=0 and non-invertible, even
when they can still be invertible and have a visible outcome.
- When m₁₁=0 or m₂₂=0 weren't caused by `transform`, it was replacing
the matrix with the identity.
Testing: Adding new WPT
Fixes: #37146
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>
Previously, after a layout was finished (or skipped in the case of
repaint-only layout), both the stacking context tree and display list
were built. In the case of repaint-only layout, we should be able to
skip the reconstruction of the stacking context tree and only do display
list building.
This change does that, also generally cleaning and up and clarifying the
data structure used during this phase of layout. This opens up the
possibility of a new kind of incremental layout that does both repaint
and a rebuild of the stacking context tree.
On the blaster.html test case[^1], this reduces tightly-measured layout
time from ~45-50 milliseconds to ~25-30 milliseconds on my M3.
[^1]: https://gist.github.com/mrobinson/44ec87d028c0198917a7715a06dd98a0
Testing: There are currently no performance tests for layout. :( This
should
not modify the results of WPT tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Instead of resolving the canvas background properties (essentially
keeping a possible reference to the `<body>`'s style) during fragment
tree construction, wait until painting to possibly find the style on an
appropriate `<body>` fragment. This is possible now because `Fragment`
keeps a list of flags with relevant information about the root and
`<body>` elements.
A benefit of this approach is that styles aren't cached in the fragment
tree, which would be problematic for incremental layout. In addition,
the old code was making an effort to transform the `<body>`'s background
by the root element's transform. Only Safari does this and there was
a resolution the WG that this should not happen in
https://github.com/w3c/csswg-drafts/issues/6683.
Testing:
- `/css/css-transforms/transform-translate-background-001.html`
- `/css/css-transforms/transform-translate-background-002.html`
- `/css/CSS2/floats/float-root.html`
Fixes: #30475.
Closes: #30569.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
In the scrollable overflow calcutation, apply CSS transforms to boxes
and scrollable overflow of the descendant. Clip unreachable scrollable
overflow according to it's block start and inline start scrolling
direction. And, renamed `Fragment::scrolling_overflow` to
`Fragment::scrolling_overflow_for_parent` as it was calculating the
scrolling overflow contribution from a child.
Add several WPT tests, testing the transform interaction `rotate`,
`scale`, and `skew` with scrollable overflow. There are several WPT test
that are testing the interaction that not expected from current browsers
implementation according to the spec.
Testing: Existing and new WPT.
Fixes: #36031
---------
Signed-off-by: stevennovaryo <steven.novaryo@gmail.com>
Instead of grouping all the `will-change` conditions together, move each
one of them next to the condition for the relevant property.
This avoids the need to call `is_transformable()` multiple times, and
will also be needed for #35391.
Testing: unneeded (no change in behavior)
Signed-off-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>
2025-04-19 10:17:03 +00:00
Renamed from components/layout_2020/display_list/stacking_context.rs (Browse further)
