This is a simple code organization change with no behavior change with
the idea of making Layout 2020 easier to understand by new folks to the
project. The idea is that we will have a cleaner separation between the
different parts of layout ie one directory for the fragment tree and one
(currently multiple) directory for the box tree.
Lay out floats and handle clearance in layout 2020, but don't flow text around them yet
This is a crude rebase of #27539
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Instead of hoisting floated fragments to be siblings of the fragment
created by their containing block formatting context, keep them in
"normal" fragment tree position and adjust their positioning to be
relative to the containing block. This means that float fragments follow
the existing invariants of the fragment tree and properly handle hit
testing, painting order, and relative positioning.
The tradeoff here is more complexity tracking the containing block
offsets from the block formatting context (including handling collapsed
margins), but less complexity dealing with hoisting / shared ownership
in addition to the correctness benefits.
Some tests are failing now because this change revealed some additional
shortcomings with clearing block formatting context content size past
the end of their contained floats. This will be fixed in a followup
change.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This commit puts floats behind the `layout.floats.enabled` pref, because of the
following issues and unimplemented features:
* Inline formatting contexts don't take floats into account, so text doesn't
flow around the floats yet.
* Non-floated block formatting contexts don't take floats into account, so BFCs
can overlap floats.
* Block formatting contexts that contain floats don't expand vertically to
contain all the floats. That is, floats can stick out the bottom of BFCs,
contra spec.
Clear PositioningContext for speculative layouts
<!-- Please describe your changes on the following line: -->
Developed in collaboration with @mrobinson
`try_layout` is used for laying out absolutely positioned descendants multiple times when min/max-{width, height} properties are set. When the same PositioningContext instance is used between successive attempts without clearing the accumulated descendants, we will generate multiple fragments which reference the same box, which then will lead to a double borrow error when layout is performed in parallel.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because crash testing is currently not working in servo. New tests will be added once #29832 is fixed.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
`try_layout` is used for laying out absolutely positioned
descendants multiple times when min/max-{width, height}
properties are set. When the same PositioningContext instance
is used between successive attempts without clearing the accumulated
descendants, we will generate multiple fragments which reference
the same box, which then will lead to a double borrow error
when layout is performed in parallel.
Signed-off-by: Mukilan Thiyagarajan <me@mukilan.in>
The specification dictates quite quite idiosyncratic return values when
querying insets of positioned elements via getComputedStyle(). These
depend on whether or not the elements size was overconstrained. This
change adds a better implementation of that in preparation for returning
proper values for position: sticky.
During layout it is often useful, for various specification reasons, to
know if an element is the `<body>` element of an `<html>` element root. There
are a couple places where a brittle heuristic is used to detect `<body>`
elements. This information is going to be even more important to
properly handle `<html>` elements that inherit their overflow property from
their `<body>` children.
Implementing this properly requires updating the DOM wrapper interface.
This check does reach up to the parent of thread-safe nodes, but this is
essentially the same kind of operation that `parent_style()` does, so is
ostensibly safe.
This change should not change any behavior and is just a preparation
step for properly handle `<body>` overflow.
This renames the helper method to be a bit more accurate. For elements
with static, relative, and sticky positioning, their containing block is
always formed by their nearest block container ancestor. This method is
really dealing with style that means an element will establish a
containing block for absolutely positioned descendants.
The calculation of the block axis positioning of absolutely positioned
elements was using the inline size of the containing block instead of
the block size.
… and converting them to flow-relative geometric values.
These values are almost always used to size and position a fragment within its containing block, so using the mode of the containing block seems more correct.
Note that the `writing-mode` and `direction` properties are disabled in Servo at the moment, so this PR by itself should have no effect: the writing mode of an element is always the same of that of its containing block since they’re both horizontal rtl.
We want to mutate them when lazily computing their content sizes, but they
are behind an Arc for the hoisting infra, so it also needs its own layer
of inner mutability.
We were previously throwing away some boxes hoisted to containing blocks
for all descendants when they were contained by absolutes. This prevents
panics in existing web platform tests that would otherwise be triggered
by the addition of the `unreachable!` statement.
This avoids the use of lookup tables for containing blocks when
constructing the stacking context tree.
This seems to catch some laid-out hoisted fragments that were otherwise
dropped in the previous design. The changes cause one new test to pass
and one to fail. Visual examination of the failing tests reveals that
it's a progression (list markers are appearing when they were previously
not rendered).
layout_2020: Use ArcRefCell in the fragment tree
This will allow mutability which is useful for things like animations.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they should not change behavior.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Add support for tracking containing blocks when doing inline layout.
This requires setting up a PositioningContext for inline boxes when
necessary. Instead of using the PositioningContext helper methods
and we reuse the contexts between line breaks.
Fixes#25279.
Add a few helper methods which allow removing duplicate code in
PositioningContext. These methods will also be used to properly
implement hoisting in inline layout.
Instead of painting hoisted position fragments in the order to which
they are hoisted, paint them in tree order and properly incorporate them
into the stacking context.
We do this by creating a placeholder fragment in the original tree position
of hoisted fragments. The ghost fragment contains an atomic id which
links back to the hoisted fragment in the containing block.
While building the stacking context, we keep track of containing blocks
and their children. When encountering a placeholder fragment we look at
the containing block's hoisted children in order to properly paint the
hoisted fragment.
One notable design modification in this change is that hoisted fragments
no longer need an AnonymousFragment as their parent. Instead they are
now direct children of the fragment that establishes their containing block.
This is a feature that was never properly implemented in the previous
layout system. We still need to preserve their in-tree order in the
display list though.
This method doesn't actually do any layout, but converts this block to a
HoistedAbsolutelyPositionedBox which is hoisted and then laid-out with
its containing block later. This makes the code a little easier to read.
