Automatic update from web-platform-tests
Paint replaced normal-flow stacking contexts inline
ReplacedNormalFlowStackingContext elements (currently <video> and SVG
<foreignObject>) have self-painting PaintLayers. BoxFragmentPainter
skips fragments with self-painting layers during PaintForegroundPhases,
deferring them to PaintLayerPainter::PaintChildren which runs later.
This causes these elements to paint after sibling inline content.
Paint these layers inline during the normal content painting phase, and
skip them in PaintChildren. Hit-test them from the same inline position
so hit testing stays in sync with paint order. This generalizes the
existing SVGForeignObjectPainter pattern, which is now redundant and
removed.
This also fixes a PaintController CHECK hit when a static video gains
controls dynamically. In that case the video becomes a replaced
normal-flow stacking context, and leaving it to be painted later through
PaintChildren can reuse the same cached subsequence through the wrong
paint path.
Bug: 505772420
Change-Id: I3c6141d1ef6360b22b6dc7172593640417cd6e8d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7813580
Reviewed-by: Philip Rogers <[email protected]>
Commit-Queue: jj <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1632703}
--
wpt-commits: d5f1e15b56249d553c774b7810143ff2cb8eddbf
wpt-pr: 59959
Automatic update from web-platform-tests
layout: Keep all trailing whitespace after unparented table-levels
A sequence of table-level boxes gets wrapped inside an anonymous table
box. This includes interleaved spaces (which table layout will skip),
but not trailing spaces, which need to be kept after the table.
We were only keeping the last such whitespace node, but it's possible
to have more than one whitespace node. So this patch keeps all nodes
after the last table-level element.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 8198c88769e8dff2299a9614f7ead1005d41c1c8
wpt-pr: 59502
Automatic update from web-platform-tests
[layout] Remove the anonymous block before reparenting children.
There was a small functional change within:
https://chromium.googlesource.com/chromium/src/+/ca6e0f7e75fbe39b2322a5352fa10e2001671a02
We have a "full_remove_insert" parameter which is used to trigger a
safer set of invalidations, as well as invoking LayoutObject::AddChild
instead of reaching into the LayoutObjectChildList and changing it
directly.
We set this parameter to "true". When the anonymous block was attached
to its parent, and we tried to reparent the abspos to the parent
block-flow the following happened:
- We'd invoke MoveAllChildrenTo(...., true);
- This would try and reparent the abspos.
- We'd invoke LayoutBlockFlow::AddChild
- This would trigger the following line:
"if (after_child && after_child->IsAnonymousBlockFlow())"
after_child was the thing we were tying to remove children from!
So the abspos would get re-inserted to the end of our anonymous block
child (which technically was correct as it was being placed before the
"before_child"). It'd process all the remaining children, then process
the abspos again, inserting it into the incorrect position now.
We want to leave this parameter to "true" always, so to fix this we just
need to remove "this" from its parent, then reparent all its children.
This means that the LayoutBlockFlow::AddChild logic doesn't see the
anonymous block-flow and doesn't get confused.
The layout-tree before and after this change.
Before:
```
LayoutView 0x134021009d8 #document
LayoutBlockFlow 0x13402100b60 HTML
LayoutBlockFlow 0x13402100c50 BODY
* LayoutBlockFlow (relative positioned) 0x13402100cf0 DIV style="position: relative;"
LayoutBlockFlow 0x13402101210 DIV id="target" style="display: block;"
LayoutBlockFlow (anonymous, children-inline) 0x134021012b0
LayoutBlockFlow (inline) 0x13402100ed0 SPAN style="display: inline-block;"
LayoutText 0x13402100f70 #text "\n "
LayoutBlockFlow (positioned) 0x13402100fe0 DIV class="abspos" style="background: green;"
LayoutBlockFlow (positioned) 0x13402100de0 DIV class="abspos" style="background: red;"
LayoutBlockFlow 0x134021010d0 DIV
```
After:
```
LayoutView 0x134021009d8 #document
LayoutBlockFlow 0x13402100b60 HTML
LayoutBlockFlow 0x13402100c50 BODY
* LayoutBlockFlow (relative positioned) 0x13402100cf0 DIV style="position: relative;"
LayoutBlockFlow (positioned) 0x13402100de0 DIV class="abspos" style="background: red;"
LayoutBlockFlow 0x13402101210 DIV id="target" style="display: block;"
LayoutBlockFlow (anonymous, children-inline) 0x134021012b0
LayoutBlockFlow (inline) 0x13402100ed0 SPAN style="display: inline-block;"
LayoutText 0x13402100f70 #text "\n "
LayoutBlockFlow (positioned) 0x13402100fe0 DIV class="abspos" style="background: green;"
LayoutBlockFlow 0x134021010d0 DIV
```
Fixed: 505179602
Change-Id: I7f229a3d670d75e4290a88671d92ad73ec1dd34f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7791943
Auto-Submit: Ian Kilpatrick <[email protected]>
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1620382}
--
wpt-commits: 6489f94bc054e4aee18a9524e00e41474f82c2b8
wpt-pr: 59457
Automatic update from web-platform-tests
[layout] Don't reinsert on float change if we are OOF-positioned.
Previously we were unnecessarily reinserting into the layout tree if our
floating status changed, but we were also OOF-positioned.
This was "fine", except the reattach logic didn't support ::backdrop
pseudo-elements. ::backdrop pseudo-elements are *always* OOF-positioned
(see the corresponding logic in the StyleAdjuster).
As such we'd crash in LayoutTreeBuilderTraversal::NextSibling as it
didn't handle ::backdrop.
Adjust the logic in ComputedStyle::NeedsReinsertLayoutTree to skip the
floating change if the style is OOF-positioned.
Fixed: 495571483
Change-Id: Icbf1e44520d60ec3054428e69ada17518665aa35
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7697590
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1604461}
--
wpt-commits: 70136573f09434763635f934ba5f58b98a03e58d
wpt-pr: 58728
Automatic update from web-platform-tests
[layout] Don't reinsert on float change if we are OOF-positioned.
Previously we were unnecessarily reinserting into the layout tree if our
floating status changed, but we were also OOF-positioned.
This was "fine", except the reattach logic didn't support ::backdrop
pseudo-elements. ::backdrop pseudo-elements are *always* OOF-positioned
(see the corresponding logic in the StyleAdjuster).
As such we'd crash in LayoutTreeBuilderTraversal::NextSibling as it
didn't handle ::backdrop.
Adjust the logic in ComputedStyle::NeedsReinsertLayoutTree to skip the
floating change if the style is OOF-positioned.
Fixed: 495571483
Change-Id: Icbf1e44520d60ec3054428e69ada17518665aa35
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7697590
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1604461}
--
wpt-commits: 70136573f09434763635f934ba5f58b98a03e58d
wpt-pr: 58728
Automatic update from web-platform-tests
[layout] Fix anonymous LayoutInline crash with new reinsert logic.
The new reinsert logic added in:
https://chromium-review.googlesource.com/c/chromium/src/+/7427180
Had an issue where the reinsert logic differed from the reattachment
logic.
The reinsert logic used:
LayoutTreeBuilderTraversal::NextSiblingLayoutObject
But the reattachment logic has additional logic within:
LayoutTreeBuild::NextLayoutObject
We should have been using the logic for reattachment. Extract this out
to a LayoutTreeBuilderTraversal::NextSiblingLayoutObjectForAttachment
and update the callsites.
Fixed: 492374383
Change-Id: I05996ffad7b756144361ce38d71f4aed078ac44b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7673932
Reviewed-by: Rune Lillesveen <[email protected]>
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1601964}
--
wpt-commits: 5a19456479f787f8b00b57b9705ac06a58498327
wpt-pr: 58616
Automatic update from web-platform-tests
layout: Fix bottom margin of block-in-inline getting ignored
In order to know whether a block box can collapse its bottom margin with
the bottom margin of its last child, we need to check its tentative
block size. Most usually, this will be the block size of the containing
block that is used when laying out the children.
However, anonymous blocks do not establish a containing block. So using
the containing block for children meant that we were using the tentative
block size of its parent. If that parent had a definite size, this would
prevent the anonymous block from collapsing bottom margins with its
children. This situation could happen when placing a block-level inside
of an inline box.
This patch fixes the problem by using an indefinite tentative block size
for anonymous blocks, instead of the containing block for children.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 33ea3abc4b7ffe1d03cac6a985d72e035a898d70
wpt-pr: 58091
Automatic update from web-platform-tests
layout: Fix abspos position when it would be preceded by phantom line
The static position of an abspos is the hypothetical position that it
would have had in the normal flow. If the abspos is inside inline layout
and it had a block-level original display, then the static position
is computed as if the abspos was a block-level that breaks the inline.
Usually this places the static position after the current line. However,
if the abspos is not preceded by any text, padding, border, margin,
preserved newline or atomic inline, then the static position should be
as if the abspos was preceded by a 0px tall phantom line. Previously we
weren't taking that into account.
Note that browsers aren't completely interoperable in corner cases.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 25bb1370e7968664ae222f07478164b2b0ace1cf
wpt-pr: 57757
Automatic update from web-platform-tests
layout: Let `OutsideMarker` store an `IndependentFormattingContext`
`OutsideMarker` was storing the `BlockFormattingContext` and the
`LayoutBoxBase` in separate fields. Now it will store an entire
`IndependentFormattingContext` in a single field.
In particular, this fixes the issue that `OutsideMarker::repair_style()`
wasn't calling `BlockFormattingContext::repair_style()`. Now we can just
rely on `IndependentFormattingContext::repair_style()`, which correctly
repairs the style of both the `BlockFormattingContext` and the
`LayoutBoxBase`.
Also, the `BlockLevelBox::repair_style()` was repairing the style of the
`LayoutBoxBase` twice, for all kinds of block-level boxes. This removes
the duplication.
Testing: Adding a new test
Fixes: 42779
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 0e65c24fb56462d7907e406d35b630a27d3974f4
wpt-pr: 58060
Automatic update from web-platform-tests
layout: Let `TableSlotCell` store an `IndependentFormattingContext`
`TableSlotCell` was storing the `BlockFormattingContext` and the
`LayoutBoxBase` in separate fields. Now it will store an entire
`IndependentFormattingContext` in a single field.
In particular, this fixes the issue that `TableSlotCell::repair_style()`
wasn't calling `BlockFormattingContext::repair_style()`. Now we can just
rely on the correct `IndependentFormattingContext::repair_style()`.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 0f8f58bca5a2efaffbc91e1660d5be8fe8678e0f
wpt-pr: 57978
Automatic update from web-platform-tests
Improve performance of `margin-collapse-through-for-various-height-values.tentative.html`
I tried to do it well when I wrote the test, but I didn't realize that
promise tests run one after the other, not in parallel.
--
wpt-commits: 6679fbba8742fdcc1b356d12bc6f15356515475d
wpt-pr: 57759
Automatic update from web-platform-tests
Map `outlines` web-feature (#56787)
Feature: `outlines`
Reference: https://github.com/web-platform-dx/web-features/blob/main/features/outlines.yml
Differentiation logic:
The `outlines` feature covers the longhand properties (`outline-width`, `outline-style`, `outline-color`, `outline-offset`). The `outline` feature covers the shorthand property. To prevent overlap, I remapped some of the the `outline` feature mapping to explicitly exclude the longhand patterns (e.g., `!outline-width-*`).
Co-authored-by: Chris Cuellar <[email protected]>
--
wpt-commits: 44ac9fbc30bd098da0598d855b8184b4f913f961
wpt-pr: 56787
Automatic update from web-platform-tests
[layout] Fix nullptr dereference within FirstLineStyleWithoutFallback
With http://crrev.com/c/7427180 its now possible to not have a parent
within FirstLineStyleWithoutFallback.
Add a nullptr check to avoid a nullptr dereference.
Bug: 476169479
Change-Id: I89d130674445239bb4003a5890a9056b9dba3779
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7489700
Reviewed-by: Koji Ishii <[email protected]>
Commit-Queue: Ian Kilpatrick <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1570988}
--
wpt-commits: b5b626509a9fffa6eea011a11b9bf6d6cfba9c13
wpt-pr: 57228
Automatic update from web-platform-tests
[layout] Avoid <fieldset> crash for float state change.
With http://crrev.com/c/7427180 its now possible to add a child to a
<fieldset> with a before_child being non-null.
We can reuse the existing logic added in http://crrev.com/c/2975047 to
select the correct before_child based on the DOM-tree.
Just avoid the if-stmt which was preventing this.
This unifies code and makes it easier to reason about.
Bug: 476180594
Change-Id: Iada4d8f7bcdab79a25d514c2ef986d2ea68eba60
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7488680
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: David Grogan <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1570611}
--
wpt-commits: f5447f6092e834d1df4b343e5f72866f7a63db74
wpt-pr: 57218
Automatic update from web-platform-tests
Reapply "[layout] Reinsert LayoutObjects which undergo a in-flow state change."
This reverts commit 07002c40c631b6ee35ee32d2bbccacc75e9052a0.
This patch reinserts layout-objects into the layout-tree when their
out-of-flow state changes. (E.g. a change from position:static to
position:absolute or float:left to float:none).
When their out-of-flow state changes we'll remove it from the
layout-object tree, update the style, then reinsert into the tree. This
is similar to layout-tree reattachment, except the layout-object (and
related objects/caches) are kept around.
This simplifies our logic when style changes in this way. Previously
we'd need to mutate the layout tree during LayoutObject::SetStyle which
was complex and error prone, and a source of bugs.
See removal patch for complexity we can remove:
https://chromium-review.googlesource.com/c/chromium/src/+/7263470
All behaviour changes should be behind the flag:
LayoutReinsertOnInFlowStateChange
Bug: 469120960
Change-Id: I983967e03d10552ad2f8cd1f70b4c3c2ea079836
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7427180
Commit-Queue: Ian Kilpatrick <[email protected]>
Reviewed-by: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1569882}
--
wpt-commits: 3166e6fb4107f8a51457bd73619356f2d6172d1d
wpt-pr: 57186
Automatic update from web-platform-tests
Map `link-selectors` web-feature (#56504)
Feature: `link-selectors`
Reference: https://github.com/web-platform-dx/web-features/blob/main/features/link-selectors.yml
Notable exclusions
1. Tests for `@scope` focusing on `css-cascade`
- `css/css-cascade/scope-visited.html`
- `css/css-cascade/scope-visited-cssom.html`
2. Tests for `all`, `revert`, `unset` properties focusing on `css-cascade`
- `css/css-cascade/all-prop-initial-visited.html`
- `css/css-cascade/all-prop-revert-visited.html`
- `css/css-cascade/all-prop-unset-visited.html`
3. Tests where `:visited` or `:link` are used primarily as setup for testing other features (e.g., backgrounds, acid tests)
- `acid/*`
- `css/CSS2/backgrounds/*`
4. Tests primarily about `:has()` interaction with link pseudo-classes (mapped to `has`)
- `css/selectors/has-visited.html`
- `css/selectors/invalidation/link-pseudo-in-has.html`
- `css/selectors/invalidation/link-pseudo-class-in-has.html`
7. Tests primarily about `:not()` interaction with link pseudo-classes (mapped to `not`)
- `css/selectors/not-links.html`
Notable inclusions
1. Tests for privacy restrictions on `:visited` (color, stroke, fill, emphasis).
- `css/selectors/text-*-visited-inheritance.html`
- `css/selectors/caret-color-visited-inheritance.html`, This test was remapped from `caret-color` to `link-selectors`
- These verify the specific behavior of `:visited` styles being restricted.
2. Tests for partitioned visited links (privacy feature)
- `css/selectors/partitioned-visited-manual.tentative.html`
3. Tests for invalidation of `:any-link`
- `css/selectors/invalidation/any-link-*.html`
--
wpt-commits: 605bc54009057067a128bd5d9ecea201aff352d8
wpt-pr: 56504
Automatic update from web-platform-tests
layout: Let floats know that margins can collapse thru phantom lines
Phantom line boxes allow margins to collapse through them. But in the
sequential layout state we were assuming that was not the case, so we
were placing floats incorrectly.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: 1053d9a4de53cc10423b1d2c7ce2da8cc51ffc44
wpt-pr: 57116
Automatic update from web-platform-tests
layout: Consider margin of preceding block when placing abspos inside inline
Now that we may have block-level boxes inside an inline formatting
context, absolutely positioned boxes need to consider that margin.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: fb675eb421ec07d27e69fde7b0d0b5e2a3b39097
wpt-pr: 56983
Automatic update from web-platform-tests
Map "static-positioning" web-feature (#56304)
Feature: `static-positioning`
Reference: https://github.com/web-platform-dx/web-features/blob/main/features/static-positioning.yml
**Notable exclusions**
1. Tests about "static position" (for absolutely positioned elements) rather than `position: static`
- `css/css-position/static-position/*` - Tests the static position calculation for absolutely positioned elements, not the `position: static` value
- `css/css-position/multicol/static-position/*` - Tests static position in multicolumn contexts for absolutely positioned elements
- `css/CSS2/positioning/absolute-*` - Tests about absolutely positioned elements that mention "static position" in their calculations
2. Tests about containing blocks for static positioned elements
- `css/CSS2/box-display/containing-block-004.xht`, `containing-block-005.xht`, `containing-block-006.xht` - Primary focus: containing block calculation, not static positioning behavior
3. Tests about other positioning features that happen to mention static positioning
- `css/CSS2/positioning/position-fixed-006.xht` - Tests that root elements may treat non-static positions as static (about fixed positioning, not static)
- `css/CSS2/floats-clear/floats-133.xht` - Tests floats with position:static (primary focus: floats)
- `css/CSS2/normal-flow/blocks-022.xht` - Tests block widths with position:static (primary focus: block box model)
4. Parsing and computed value tests for the position property, don't use "static" as value
- `css/css-position/parsing/position-valid.html`
- `css/css-position/parsing/position-computed.html`
- `css/css-position/animations/position-interpolation.html`
5. Tests about cross-cutting concerns
- `css/css-position/inheritance.html` - Uses static as initial value, but tests inheritance
--
wpt-commits: 8d2a0bbacbc01b64aa53b53a0740ed0d0846fad3
wpt-pr: 56304
Ahmad Saleem