Detect body elements during layout#29699
Merged
bors-servo merged 1 commit intoservo:masterfrom May 4, 2023
Merged
Conversation
4 tasks
Member
Author
|
@bors-servo try=wpt |
Contributor
bors-servo
added a commit
that referenced
this pull request
May 2, 2023
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. -->
|
Test results for linux-wpt-layout-2013 from try job (#4858424004): Flaky unexpected result (16)
Stable unexpected results that are known to be intermittent (10)
Stable unexpected results (1)
|
Contributor
|
💔 Test failed - checks-github |
mrobinson
force-pushed
the
add-html-body-tag
branch
2 times, most recently
from
5bafedd to
88d29a8
Compare
mukilan
reviewed
May 4, 2023
| } | ||
| } | ||
|
|
||
| impl<'dom, Node> Into<BaseFragmentInfo> for &NodeAndStyleInfo<Node> |
Member
There was a problem hiding this comment.
The std doc recommends implementing From over Into. Just curious if we have made a deliberate choice to implement Into here.
Member
Author
There was a problem hiding this comment.
Great point I've converted this and the other Into implementation into From.
mukilan
reviewed
May 4, 2023
|
|
||
| impl Tag { | ||
| /// Create a new Tag for a non-pseudo element. This is mainly used for | ||
| /// matching existing tags, since it does not accept an `info` argument. |
Member
There was a problem hiding this comment.
nit: Additional space at the beginning can be removed.
mukilan
reviewed
May 4, 2023
| } | ||
|
|
||
| /// Create a new Tag for a pseudo element. This is mainly used for | ||
| /// matching existing tags, since it does not accept an `info` argument. |
Member
There was a problem hiding this comment.
nit: Additional space at the beginning can be removed.
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.
mrobinson
force-pushed
the
add-html-body-tag
branch
from
88d29a8 to
72302e2
Compare
Member
|
@bors-servo r+ |
Contributor
|
📌 Commit 72302e2 has been approved by |
Contributor
mukilan
approved these changes
May 4, 2023
|
Test results for linux-wpt-layout-2013 from try job (#4881254848): Flaky unexpected result (19)
Stable unexpected results that are known to be intermittent (9)
|
Contributor
|
☀️ Test successful - checks-github |
3 tasks
|
Test results for linux-wpt-layout-2020 from try job (#4885422084): Flaky unexpected result (1)
Stable unexpected results that are known to be intermittent (7)
Stable unexpected results (51)
|
|
Test results for linux-wpt-layout-2020 from try job (#4885767073): Flaky unexpected result (1)
Stable unexpected results that are known to be intermittent (7)
Stable unexpected results (51)
|
|
Test results for linux-wpt-layout-2020 from try job (#4890001583): Flaky unexpected result (2)Stable unexpected results that are known to be intermittent (7)
Stable unexpected results (51)
|
Loirooriol
added a commit
to Loirooriol/servo
that referenced
this pull request
Dec 10, 2025
These structs used to be different when they were added in servo#29699: `BaseFragment` had a `debug_id` field, while `BaseFragmentInfo` didn't. But this field was later removed in servo#35001, so the structs became identical. Therefore, this just unified them. I'm picking `BaseFragmentInfo` as the name, since it was the most frequently used of the two. Signed-off-by: Oriol Brufau <[email protected]>
Loirooriol
added a commit
to Loirooriol/servo
that referenced
this pull request
Dec 10, 2025
These structs used to be different when they were added in servo#29699: `BaseFragment` had a `debug_id` field, while `BaseFragmentInfo` didn't. But this field was later removed in servo#35001, so the structs became identical. Therefore, this just unified them. I'm picking `BaseFragmentInfo` as the name, since it was the most frequently used of the two. Signed-off-by: Oriol Brufau <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 10, 2025
These structs used to be different when they were added in #29699: `BaseFragment` had a `debug_id` field, while `BaseFragmentInfo` didn't. But this field was later removed in #35001, so the structs became identical. Therefore, this patch just unifies them. I'm picking `BaseFragmentInfo` as the name, since it was the most frequently used of the two. Testing: Not needed, no change in behavior Signed-off-by: Oriol Brufau <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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../mach build -ddoes not report any errors./mach test-tidydoes not report any errors