Automatic update from web-platform-tests
[text-box-trim] Fix for nested lists
This patch fixes unwanted vertical gaps when `text-box-trim`
is applied to nested lists. It involves two changes:
1. Prevents the list marker from pushing the content down when
the content is trimmed but the marker is not.
2. Ensures that anonymous block wrappers for list item content
are correctly identified as containing the first formatted
line, even when preceded by the outside list marker in the
layout tree.
Bug: 512046827
Change-Id: If3743b908c6a407a1fd4b24b41070961300a5165
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7849539
Auto-Submit: Koji Ishii <[email protected]>
Reviewed-by: Kent Tamura <[email protected]>
Commit-Queue: Kent Tamura <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1632446}
--
wpt-commits: 2fc5ea78b499e0d296856dd3644babea7b3fdd70
wpt-pr: 59958
Also adds WPT reftests to validate alignment behavior in horizontal and vertical
writing modes with the different `alignment-baseline` values. Additionally:
- The `alignment-baseline: middle` tests have failing expectations. This is
because the existing implementation does not match the css-inline-3 definition
(which the new WPTs follow). See Bug 2030203.
- The WidthTest-Regular.otf support font was updated to remove its unusual
ideographic-under baseline value, which affected its synthesized central
baseline. With the new support for `alignment-baseline: central`, this broke a
number of `text-combine-upright-compression-*` WPT reftests. The non-centered
baseline values were removed from this test using FontForge, so that the
synthesized central baseline matched the expectation of the test references.
Differential Revision: https://phabricator.services.mozilla.com/D292136
This reverts commit 482c9f881b.
Revert "Bug 2029869 - Synthesize vertical font metrics/baselines from horizontal metrics/baselines. r=layout-reviewers,jfkthame"
This reverts commit 8699ee2727.
Also adds WPT reftests to validate alignment behavior in horizontal and vertical
writing modes with the different `alignment-baseline` values. Additionally:
- The `alignment-baseline: middle` tests have failing expectations. This is
because the existing implementation does not match the css-inline-3 definition
(which the new WPTs follow). See Bug 2030203.
- The WidthTest-Regular.otf support font was updated to remove its unusual
ideographic-under baseline value, which affected its synthesized central
baseline. With the new support for `alignment-baseline: central`, this broke a
number of `text-combine-upright-compression-*` WPT reftests. The non-centered
baseline values were removed from this test using FontForge, so that the
synthesized central baseline matched the expectation of the test references.
Differential Revision: https://phabricator.services.mozilla.com/D292136
Moves the existing dominant-baseline CSS property out from SVG-specific
struct and into the general inherited box struct. Also adds new WPTs for
testing dominant-baseline against the alignment-baseline property.
Differential Revision: https://phabricator.services.mozilla.com/D282788
Replaces the `vertical-align` longhand with the shorthand version and the corresponding `alignment-baseline` and `baseline-shift` longhands (the `baseline-source` property was already implemented). Some notes about this change:
- The CSS Inline Layout Module Level 3 specification introduced new
values to `alignment-baseline` and `baseline-shift` that were not
available in the original `vertical-align` longhand. This change
only implements the original keywords; the new values will be used
in a future patch.
- The SVG layout still ignores the `vertical-align` (and now the
corresponding longhands) in favor of the `dominant-baseline`. This
will also be addressed in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D277725
Automatic update from web-platform-tests
Don't recalc ::first-letter ancestors for interleaved root
RecalcStyleForTraversalRootAncestor() should only clear flags for
interleaved style recalc. If ancestors of the interleave root needed
update, like ::first-letter updates, we would not be safely contained to
allow interleaving in the first place.
Bug: 457241503
Change-Id: I3c45ed0e7d7ad02bc9950f568d17c0e3ec2fcf11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7459070
Commit-Queue: Rune Lillesveen <[email protected]>
Reviewed-by: Anders Hartvoll Ruud <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1568492}
--
wpt-commits: 7734d01787e95a72a1541a8cc79e9c10b9a718c1
wpt-pr: 57153
Automatic update from web-platform-tests
Move animations/composition/baseline-shift-composition.html to WPT
Move the test and perform a mechanical rewrite:
* Change assertComposition() to test_composition().
* Change 'is' to 'expect' in the expectation objects.
* Include required testharness.js and framework.
* Add link to spec.
Bug: 40663834
Change-Id: I3054b6153efaa652b9703794ce823d08e5416268
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7185724
Auto-Submit: Fredrik Söderquist <[email protected]>
Reviewed-by: Kevin Ellis <[email protected]>
Commit-Queue: Kevin Ellis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1548529}
--
wpt-commits: 91eaa6dca62bf606e3d75df3506bc4dc0fb05e0a
wpt-pr: 56192
Automatic update from web-platform-tests
layout: Make lines non-phantom if they have inline padding/border/margin
According to https://drafts.csswg.org/css-inline/#invisible-line-boxes,
if a line box contains non-zero inline-axis margins, padding or borders,
then it can't be phantom.
Therefore, this patch makes adds a `has_inline_pbm` flag to the line.
Note that we can't use the `has_content` flag, because that would add
a soft wrap wrap opportunity between the padding/border/margin and the
first content of the line.
The patch also renames `InlineFormattingContext::had_inflow_content` to
`has_line_boxes`, which is what we care about for collapsing margins
through.
Signed-off-by: Oriol Brufau <[email protected]>
--
wpt-commits: bc09e43bd500cb3dbaea0ef57ff4cabb94cc7efe
wpt-pr: 54833
Automatic update from web-platform-tests
Reland "[line-clamp] Support clamping by lines and a height at the same time"
This is a reland of commit 042edf71969098eaaedcfd003de4f01a2b448a64
Original change's description:
> [line-clamp] Support clamping by lines and a height at the same time
>
> Until now, in our implementation of `line-clamp`, we allowed clamping
> by a number of lines (e.g. `line-clamp: 3`), and clamping by a block
> size (e.g. `line-clamp: auto`, with a block size constraint given by
> `max-height`, for example); but we did not support clamping by both.
> If `line-clamp: 3` was set on a container with a height that did not
> fully fit the third line, that line would overflow, but the clamp
> point would not be moved earlier.
>
> However, in the April CSSWG F2F, it was discussed that clamping by
> both lines and a block size should be possible. This was not resolved
> at that point, since this was tangential to the issue that was being
> discussed, but the working group seemed to lean in that direction.
>
> We implement this by adding a new value to the `LineClampData::State`
> enum, `kClampByLinesWithBfcOffset`. This state will both act as if
> clamping by a number of lines, while at the same time checking if we
> ever go past the BFC offset before the clamp point, in which case we
> relayout using regular `kClampByLines`.
>
> Bug: 40336192
> Change-Id: I2519c9f84b3ca41aa9418c435bea978bfe1fec73
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6757119
> Reviewed-by: Ian Kilpatrick <[email protected]>
> Commit-Queue: Andreu Botella <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#1491158}
Bug: 40336192
Change-Id: If15fc543b068f36c181b37c007581d2e04aa16c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6838616
Reviewed-by: Ian Kilpatrick <[email protected]>
Commit-Queue: Andreu Botella <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1501621}
--
wpt-commits: d96e88d3971db97940ad52c67a9047d407fe9292
wpt-pr: 54331
Automatic update from web-platform-tests
Revert "[line-clamp] Support clamping by lines and a height at the same time"
This reverts commit 042edf71969098eaaedcfd003de4f01a2b448a64.
Reason for revert: This CL unintentionally enabled clamping by lines
and a height at the same time even without the `CSSLineClamp` runtime
enabled feature set, causing it to apply to `-webkit-line-clamp`. This
new behavior seems to have broken at least some sites.
Original change's description:
> [line-clamp] Support clamping by lines and a height at the same time
>
> Until now, in our implementation of `line-clamp`, we allowed clamping
> by a number of lines (e.g. `line-clamp: 3`), and clamping by a block
> size (e.g. `line-clamp: auto`, with a block size constraint given by
> `max-height`, for example); but we did not support clamping by both.
> If `line-clamp: 3` was set on a container with a height that did not
> fully fit the third line, that line would overflow, but the clamp
> point would not be moved earlier.
>
> However, in the April CSSWG F2F, it was discussed that clamping by
> both lines and a block size should be possible. This was not resolved
> at that point, since this was tangential to the issue that was being
> discussed, but the working group seemed to lean in that direction.
>
> We implement this by adding a new value to the `LineClampData::State`
> enum, `kClampByLinesWithBfcOffset`. This state will both act as if
> clamping by a number of lines, while at the same time checking if we
> ever go past the BFC offset before the clamp point, in which case we
> relayout using regular `kClampByLines`.
>
> Bug: 40336192
> Change-Id: I2519c9f84b3ca41aa9418c435bea978bfe1fec73
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6757119
> Reviewed-by: Ian Kilpatrick <[email protected]>
> Commit-Queue: Andreu Botella <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#1491158}
Bug: 40336192, 436345865
Change-Id: Ib6afb94bb4efd6b4deca166213ab2266aa123565
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6836376
Reviewed-by: Ian Kilpatrick <[email protected]>
Commit-Queue: Andreu Botella <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1499689}
--
wpt-commits: 2ce20f7d0573308bfbcec340da0b0c7ba6044045
wpt-pr: 54235
Automatic update from web-platform-tests
[line-clamp] Support clamping by lines and a height at the same time
Until now, in our implementation of `line-clamp`, we allowed clamping
by a number of lines (e.g. `line-clamp: 3`), and clamping by a block
size (e.g. `line-clamp: auto`, with a block size constraint given by
`max-height`, for example); but we did not support clamping by both.
If `line-clamp: 3` was set on a container with a height that did not
fully fit the third line, that line would overflow, but the clamp
point would not be moved earlier.
However, in the April CSSWG F2F, it was discussed that clamping by
both lines and a block size should be possible. This was not resolved
at that point, since this was tangential to the issue that was being
discussed, but the working group seemed to lean in that direction.
We implement this by adding a new value to the `LineClampData::State`
enum, `kClampByLinesWithBfcOffset`. This state will both act as if
clamping by a number of lines, while at the same time checking if we
ever go past the BFC offset before the clamp point, in which case we
relayout using regular `kClampByLines`.
Bug: 40336192
Change-Id: I2519c9f84b3ca41aa9418c435bea978bfe1fec73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6757119
Reviewed-by: Ian Kilpatrick <[email protected]>
Commit-Queue: Andreu Botella <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1491158}
--
wpt-commits: b8e67c9274874a23eed072bc9b3935523931a244
wpt-pr: 53850
Automatic update from web-platform-tests
Update tests for print-color-adjust. (#51723)
Specify `print-color-adjust:exact` in tests that test background
printing.
This is in preparation for disabling backgrounds by default when
WPT-printing (just like browsers do), so that
`print-color-adjust:economy` (the initial value) can be tested at all.
See crrev.com/c/6408671
Bug: 376381169
Change-Id: Ibddb01164e86c0f3bcc4fcdb2a7cba40a1a8c718
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6408631
Reviewed-by: Chris Harrelson <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1440518}
Co-authored-by: Morten Stenshorne <[email protected]>
--
wpt-commits: b5ded362cc5e3e5a25415def9cb67cafb64d35e5
wpt-pr: 51723
Automatic update from web-platform-tests
Map alignment-baseline and baseline-shift tests to web-features (#51656)
These are very surface-level tests, it appears that there are no tests
for the effect of these properties on layout.
--
wpt-commits: 36562e86005e82a0b678d961b573ffdbd5ddb25d
wpt-pr: 51656
Automatic update from web-platform-tests
[text-box-trim] Trim leading / trailing column spanners.
Add support for text-box-trim to the column layout algorithm. Previously
we'd rely on the block layout algorithm for column content, but with no
support for spanners.
Bug: 388523921
Change-Id: Id03290ca3510b54c38c4686ddc82b2322c6c663b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6308806
Reviewed-by: Koji Ishii <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1426265}
--
wpt-commits: 73528ff007ef40d07c1b46c982bbcf013cdf6333
wpt-pr: 51020
Automatic update from web-platform-tests
[text-box-trim] Handle new-BFC children correctly.
Text box trimming was only handled on same-formatting-context children,
but new-block-formatting-context children should also participate in
text box trimming.
Change-Id: I5e80a8510d6cf4c37b1509754797f08ca30487c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6308805
Commit-Queue: Morten Stenshorne <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1426246}
--
wpt-commits: d034690f8823a89db9563a414b6933f4690a4d12
wpt-pr: 51021
Automatic update from web-platform-tests
[text-box-trim] Rewind the stream when `ConsumeTextBoxEdge` fails
This patch fixes `ConsumeTextBoxEdge` to rewind the input
stream if the parsing fails in the middle of the consumption.
Bug: 385160696
Change-Id: Ib8ffbf6ab9731dd4443536ef13abefe5c354b63c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6151521
Reviewed-by: Kent Tamura <[email protected]>
Auto-Submit: Koji Ishii <[email protected]>
Commit-Queue: Kent Tamura <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1403286}
--
wpt-commits: 2ac6e8864f47c6dcd3db5585dff7193e9cafd6d7
wpt-pr: 49965
Automatic update from web-platform-tests
[text-box-trim] Fix `text-box-trim-on-button.html`
This CL fixes a typo in the font name of the test.
This patch has no behavior changes.
Fixed: 386860172
Change-Id: I8d324101bb5eb073e82ee5e56e0efae148d40f12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6151520
Auto-Submit: Koji Ishii <[email protected]>
Commit-Queue: Lingqi Chi <[email protected]>
Reviewed-by: Lingqi Chi <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1402970}
--
wpt-commits: a072636799691b005741df533d586f03bc471794
wpt-pr: 49952
Automatic update from web-platform-tests
WebKit export: `text-box` is not working correctly on buttons in Safari (#49880)
https://bugs.webkit.org/show_bug.cgi?id=284683
Co-authored-by: Alan Baradlay <[email protected]>
--
wpt-commits: 227803bdb90b192c8ad60bcad9be8b0cbb649e9b
wpt-pr: 49880
Automatic update from web-platform-tests
[text-box-trim] Retire text-box-edge propagation restriction
We added a restriction that the effective text-box-edge can be
propagated to its child only if the same node defines a non-initial
text-box-trim value when text-box-edge is not inherited.
But now the specification is updated[1] which marks text-box-edge as
inherited, and we no longer need this restriction.
This CL also removes
text-box-trim/text-box-trim-ignore-nested-text-box-edge.html
from the web-test. This test was replaces by
text-box-trim-not-ignore-nested-text-box-edge.html (each test
disagrees with the other) since [2], but for some reasons still stays
at the wpt codebase.
A follow-up will retire the EffectiveTextBoxEdge field.
[1] https://github.com/w3c/csswg-drafts/issues/10904
[2] https://github.com/web-platform-tests/wpt/commit/288ee9d3430ff09a227f1c96b3cbb25170ab1af4
Bug: 367766472, 374787320, 40254880
Change-Id: I789136ef54fa2d0c8b7a97b08caf1217512d10c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038647
Commit-Queue: Koji Ishii <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1388218}
--
wpt-commits: 7a76ca95714d34551bbd07245b270f2f1af07cab
wpt-pr: 49375
Automatic update from web-platform-tests
[text-box-trim] fix wrong reference to font
text-box-trim-accumulation-002/003/004 were failing due to the wrong
path to font file.
This CL fixes them and removes them from TestExpectations
Bug: 374787320
Change-Id: I4e715570f4dc14d6a56af21140f9969abc697a5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038442
Reviewed-by: Koji Ishii <[email protected]>
Commit-Queue: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1386711}
--
wpt-commits: dab0a73ae47a8278608ccf92722458ac6e6805e9
wpt-pr: 49328
Also add meta viewport tag to the setup of `/FileAPI/url/url-in-tags.window.js`
WPT - This test passes now, but without this change, the test's viewport gets
automatically zoomed out when run on Android; and that zoom factor can lead to
off-by-one test failures from pixel-rounding discrepancies.
Differential Revision: https://phabricator.services.mozilla.com/D229191
Automatic update from web-platform-tests
[text-box-trim] Extract common test values
This patch extraccts common test values to an external file.
This patch has no behavior changes.
Bug: 40254880
Change-Id: I58ce558bb40831a92a2f5c8fcd066ed1f2ff4700
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6018683
Reviewed-by: Kent Tamura <[email protected]>
Auto-Submit: Koji Ishii <[email protected]>
Commit-Queue: Koji Ishii <[email protected]>
Commit-Queue: Kent Tamura <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1382828}
--
wpt-commits: 7ad6e07dcc935cea84e7636d2252d85108184dc6
wpt-pr: 49163
Automatic update from web-platform-tests
[text-box-trim] Change `text-box-edge` to require two values
This patch changes the `text-box-edge` property to require two
values if the `over` and the `under` are different, as per the
resolution at the CSS WG[1]:
[1]: https://github.com/w3c/csswg-drafts/issues/10703
Bug: 373867786, 40254880
Change-Id: I385bf5fa1fdb45cd6990f1a079878f5a683d8712
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6017004
Reviewed-by: Kent Tamura <[email protected]>
Auto-Submit: Koji Ishii <[email protected]>
Commit-Queue: Kent Tamura <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1382625}
--
wpt-commits: 152ce7bb8a35f2556fbdee5a6021edab69709ba5
wpt-pr: 49156
Automatic update from web-platform-tests
[line-clamp] [text-box-trim] Make block-in-inlines work
This patch makes block-in-inlines work together with
`line-clamp: auto` and `text-box-trim`. There are a few reasons why
they did not previously work:
- The code in `BlockLayoutAlgorithm::FinishInflow` that handled the
interaction of these features assumed that, with `trim-end`, every
fragment with a break token would have a non-null `TrimBlockEndBy`
set. This is not true for block-in-inline wrapper lines, so this was
causing a crash.
This code is used when figuring out how many lines fit in the given
height, and it does so by always trimming by the end, and then,
after we know this line fits, re-adding that trimmed block size.
For block-in-inlines, if the inside trimmed, that trimmed block size
would have already been added when laying out the inner block.
Therefore, if there is no `TrimBlockEndBy`, we don't need to add
any block size.
- Another issue is that, when doing relayout for `text-box-trim`,
which is now only needed with block-in-inlines, the number of lines
until clamp was set to the number of lines until clamp that the
previous block layout algorithm had when it aborted. This resulted
in any lines that were laid out twice being counted twice. This
number should instead be reset to its initial value at relayout
time. Therefore we added an `initial_lines_until_clamp` field to
`BlockLineClampData` to store this value.
- Finally, although the block-in-inline tracked by
`BlockLayoutAlgorithm::last_non_empty_inflow_child_` might not be
the one that contains the last line before clamp, this shouldn't
matter after https://crrev.com/c/5987915. However, if a block ends
with a block-in-inline which comes after the clamp point, it would
cause an unnecessary relayout, because the trim-end has already been
applied to the last line before clamp in the current layout.
Therefore, we don't do this layout when we have clamped previously.
Bug: 40336192, 40254880, 372531320
Change-Id: Id228951b5db3c4bf799010e730983558567e9ddd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5987917
Commit-Queue: Andreu Botella <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1380464}
--
wpt-commits: 3241773f5849083927b5a25175326b0306f2dafc
wpt-pr: 49030
Automatic update from web-platform-tests
[line-clamp] [text-box-trim] Trim the last line before clamp inside nested blocks
When `text-box-trim: trim-end` is used together with `line-clamp`, it
should trim the block-end leading of the last line before clamp, the
one with the ellipsis. This worked when that last line before clamp is
directly contained by the line-clamp container, but it doesn't when it
is inside a nested block element.
The reason for this is that, although for `InlineNode`s,
`ConstraintSpace::ShouldTextBoxTrimNodeEnd` is always set if the
parent `BlockNode` is as well; for `BlockNode`s, that flag is only set
for nodes that are the last in-flow child node of its parent.
This means that, for line-clamp, there is no flag to tell a child
`BlockNode` that it is fine to trim if there's a clamp point inside
it, even if it wouldn't be fine to trim in its last formatted line.
This patch therefore adds a `ShouldTextBoxTrimInsideWhenLineClamp`
field to `ConstraintSpace` to indicate this.
Bug: 40336192, 40254880
Change-Id: I1690ab296dd9686a09f4b9f06a7d86d8998d9446
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5987915
Commit-Queue: Andreu Botella <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1379720}
--
wpt-commits: 23f125f385523d1e5f9777ceba49b225848b81cc
wpt-pr: 49018
Automatic update from web-platform-tests
[text-box-trim] Correct detection of intervening border/padding.
Replace what crrev.com/c/5905670 did. The detection code is now in
BlockLayoutAlgorithm().
Border / padding at the container that establishes box trimming
shouldn't be considered to be intervening. Only check border/padding on
descendants.
Bug: 40254880
Change-Id: I45b7c28f5dd37df20eb90c377759642fd3b76ed1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5960337
Reviewed-by: Koji Ishii <[email protected]>
Commit-Queue: Morten Stenshorne <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1374580}
--
wpt-commits: f3b286e22c180ac321aeae674101539b9683aca4
wpt-pr: 48838
Automatic update from web-platform-tests
[text-box-trim] Make it work on floats / OOFs.
Just use LayoutInputNode's IsFloatingOrOutOfFlowPositioned(), rather
than that of the node's LayoutObject / LayoutBox.
The LayoutBox of an InlineNode is the container, and the container's
out-of-flowness doesn't matter for the lines inside. Lines are always
considered to be in-flow.
Bug: 40254880
Change-Id: Id0f7965963ad17098e7bdbb5ba777c1d885f1829
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5961784
Commit-Queue: Morten Stenshorne <[email protected]>
Reviewed-by: Koji Ishii <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1374568}
--
wpt-commits: e11b84bcd09cf29030655ae90920426b9cc1e50a
wpt-pr: 48836
Seva Alipov