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.
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.
This moves more members to the CompositorDisplayListInfo struct, which
now holds all miscellaneous, non-WebRender data when sending display
lists. It also documents what each things sent with a display list does.
This will allow the compositor to properly chain scrolling requests up
when a node has reached the extent of the scroll area. This fixes
scrolling on servo.org.
This change refactors how layout is done in Layout 2020 in preparation
for a compositor-side scroll tree:
1. Now the SpatialId and ClipId of each fragment is stored separately.
This will allow storing a scroll node id instead of only the handle
to the WebRender spatial node.
2. Separate out stacking context tree construction and display list
building. This change will make it possible to eventually build the
stacking context tree without the full display list if we find that
necessary. For instance, this might be useful to cache containing
block boundaries.
3. Add a `DisplayList` struct that stores both the WebRender display
list builder and the compositor info. This exposes the API to the
layout thread for display list building.
In addition, this change adds a lot of missing documentation. This
should not change behavior.
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.
Detect body elements during layout
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.
<!-- 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
- [x] These changes do not require tests because it does 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. -->
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.
Implement outline-offset in layout-2020
Tests that are now passing:
- /_mozilla/css/outline_offset_a.htm
- /css/css-ui/outline-010.html
- /css/css-ui/outline-012.html
- /css/css-ui/outline-013.html
- /css/css-ui/outline-017.html
- /css/css-ui/outline-negative-offset-composited-scroll.html
- /css/css-ui/outline-offset-001.html
- /css/css-ui/outline-offset-table-001.html
- /css/css-ui/outline-offset.html
- /css/css-ui/parsing/outline-offset-computed.html
- /css/css-ui/parsing/outline-offset-valid.html
Also improvements in:
- /_mozilla/mozilla/calc.html
- /css/css-ui/animation/outline-offset-interpolation.html
- /css/css-ui/inheritance.html
<!-- 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
- [X] These changes fix#29701
<!-- 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. -->
Manage containing blocks and WebRender SpaceAndClip during stacking
context tree constuction using the ContainingBlockInfo data structure.
This will allow us to reuse this data structure whenever we traverse the
fragment tree. In addition, StackingContextBuilder is no longer
necessary at all. This change also fixes some bugs where fixed position
fragments were not placed in the correct spatial node. Unfortunately,
these fixes are difficult to test because of #29659.
WebRender already seems to be doing this normalization, but this is
needed by inner_radii in order to properly compute the reduced radii
when background-clip is content-box or padding-box.
This will also be needed for expanding the radii for box-shadow or
outline.
Test: css/css-backgrounds/background-rounded-image-clip-002.html
Fix corner clipping typos in layout-2020
<!-- Please describe your changes on the following line: -->
inner_radii() had a minus sign that shouldn't be there.
And padding_edge_clip() and content_edge_clip() clearly need to to use
the padding_rect() and content_rect() instead of border_rect.
Tests:
- css/css-backgrounds/background-clip-padding-box-with-border-radius.html
- css/css-backgrounds/background-rounded-image-clip.html
---
<!-- 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
- [X] These changes fix#29683 (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. -->
inner_radii() had a minus sign that shouldn't be there.
And padding_edge_clip() and content_edge_clip() clearly need to to use
the padding_rect() and content_rect() instead of border_rect.
Tests:
- css/css-backgrounds/background-clip-padding-box-with-border-radius.html
- css/css-backgrounds/background-rounded-image-clip.html
Previously the thickness coming from font metrics could be something
like 0.7px, so with 1dppx it would be painted as either 1 or 0 device
pixels.
Enforcing at least 1 device pixel ensures that the decoration will be
visible, and rounding to an integral amount of device pixels ensures
that the thickness won't vary depending on the position.
The specification requires this behavior when text-decoration-thickness
is set to a length or percentage. It's not clear if it should also
happen by default, but this seems to match other browsers (except for
WebKit rounding up instead of to the nearest integer).
The test text-decoration-thickness-from-zero-sized-font.html is now
failing because of #29675.
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.
This change adds support for the <iframe> element to Layout 2020. In
addition, certain aspects of the implementation are made the same
between both layout systems.
Store hit testing information in a data structure that sits alongside
the display list in the compositor. This will allow the compositor to
store more information per-node. The data structure also takes care of
de-duplicating information between successive display list entries. In
the future, the data structure can be even more aggressive in producing
smaller side hit testing lists, if necessary.
- Also updates raqote to latest with an upgrade of font-kit to 0.11
applied on as a patch
- Update lyon_geom to the latest version
Major change:
- All matrices are now stored in row major order. This means that
parameters to rotation functions no longer should be negated.
- `post_...()` functions are now named `then()`. `pre_transform()` is removed,
so `then()` is used and the order of operations changed.
Update webrender
These changes reflect changes in webrender's API that make RenderApiSender and RenderApi objects more challenging to share. This PR moves us to a model where:
* the compositor owns the main RenderApi object
* other threads that need to create transactions or manipulate fonts proxy those operations to the compositor (script/layout use IPC, while other threads use non-IPC channels)
* the webgl thread owns its own independent RenderApi
Don't create empty stacking contexts in display lists
A recent change to euclid exposed that our display lists can contain Rects that contain NaN values. These NaNs originate from creating stacking contexts with transforms that scale the horizontal or vertical dimensions to 0. WebRender isn't prepared to handle these, so we need to not produce these empty stacking contexts when building the display list.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#26592 and fix#26590
- [x] There are tests for these changes
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. -->
Partial text decoration support for layout 2020
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#25166
- [X] There are tests for these changes
