Update tests for DAP proximity events

Update storagesize6xml.xml

…Events

PointerEvents pages updates per WG and jacobrossi feedback

…the WPT innerText getter test.

Depends on D45159

Differential Revision: https://phabricator.services.mozilla.com/D46186

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1241631
gecko-commit: 4dc6ff8d58b31c747e519abcbe01270d01d66636
gecko-integration-branch: autoland
gecko-reviewers: mats

It should only be definite if the element already had a definite main
size or if the container has a definite main size.

This is #2 from https://drafts.csswg.org/css-flexbox/#definite-sizes

Bug: 845235
Change-Id: I0230080d22ada93ebc8bae09aeda629d87cf5b6d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1797442
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698790}

…iner height

See stack trace below. We set the override container logical height to -1
for the initial layout of a flex item so that we compute the correct size
for min-height. However, that messes with our cache for definite heights
because we would always set it to indefinite in such a case.

Instead, just don't cache these values. That way we will later compute the right
thing for resolving flex-basis, etc.

(FlexNG can't come soon enough...)

 #0  blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198,
    out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833
 #1  0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010,
    child=..., flex_basis=Length(0%, Percent), add_to_cb=false)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762
 #2  0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125
 web-platform-tests#3  0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137
 web-platform-tests#4  0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation (
    this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333
 web-platform-tests#5  0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (
    this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830
 web-platform-tests#6  0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198)
    at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64
 web-platform-tests#7  0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths (
    this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px)
    at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48
 web-platform-tests#8  0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509
 web-platform-tests#9  0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395
 web-platform-tests#10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198,
    child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890
 web-platform-tests#11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198,
    algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203
 web-platform-tests#12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198,
    relayout_children=true, layout_scope=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934
 web-platform-tests#13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198,
    relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369

Bug: 1019138
Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514
Commit-Queue: David Grogan <dgrogan@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713296}

With this CL, recursive custom element constructions are no
longer allowed. I.e. this will now only run the constructor once:
  class extends HTMLElement {
    constructor() {
      super();
      customElements.upgrade(this);
    }
  }

Previously, the code and spec had a bug which caused the above
code snippet to infinitely recurse. In [1] the spec has changed,
to set the custom element state to "failed" before the constructor
is called. With this change in place, recursive calls will
early-out at step #2 (of [2]), and avoid the recursion.

[1] whatwg/html#5126
[2] https://html.spec.whatwg.org/multipage/custom-elements.html#upgrades

Bug: 966472
Change-Id: I76e88c0b70132eee2482c304ef9e727ae1fe8fc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1931644
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Cr-Commit-Position: refs/heads/master@{#727841}

Paint worklet already works with custom property animation running
on the compositor thread, the requirement is that we need
“will-change: transform” for the paint worklet element. Without
that, the custom property animation will run on the main thread,
such as this example: https://output.jsbin.com/muwiyux/quiet.

This CL makes changes such that a custom property animation will
always be composited as long as it is used by paint worklet, even
if the element doesn't have "will-change: transform".

The change is actually small, there are only two things we need:
1. Start the animation on compositor.
2. Ensure the compositor ticks the animation.

For #1, we add a "has_paint_worklet_with_custom_prop_anim" in
the Animation::PreCommit, when it is true, we always composite
the animation.

For #2, we give a special ElementId which is uint64_t::max() to
the paint worklet element, and on the CC side, once we see that
element id, we know that the animation associated with that should
be ticking even if the element id doesn't have anything associated
on the property tree.

Bug: 987969
Change-Id: Ia849640065470e529a2b8d23a4b7b74339831c48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2359370
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#812056}

There were some crashes caused by nested slots (e.g.
<slot><slot>Content</slot></slot>) being removed from the tree.
These crashes were triggered by [1], which removed Shadow DOM v0, but
my theory is that due to the old V0 shadow root code, more calls were
being made to SlotAssignment::RecalcAssignment(). Now that the V0 code
is gone, it has exposed some missing code.

Three issues are being fixed here:
 1. In Node::CheckSlotChange(), while removing the inner nested slot,
    the parent_slot will have already been removed from the tree, so we
    only need to call DidSlotChange if not. This used to be a DCHECK.
 2. In TreeOrderedMap::Get(), while removing a key that previously had
    more than one element, we may walk the tree and find that none of
    the pre-existing elements are present. I.e. we're in a RemoveScope.
    In this case, the key should be removed from the map.
 3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can
    just early-out if the slot isn't present in the map.

I added a test for the crash conditions (variations on removing nested
named and unnamed slots), plus I added a test for the TreeOrderedMap
class, since there was none previously. The last test in the set
documents the new Get() behavior. I also tried to improve some of the
comments along the way. Finally, this CL rolls back a mitigation [2]
previously landed for this crash.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967

Bug: 1159328, 1159727
Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Yu Han <yuzhehan@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Cr-Commit-Position: refs/heads/master@{#838974}

…owRoot"

This reverts commit dbfed21f94881a2918223792ebde3476b8fd69e6.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 838974 as the
culprit for failures in the build cycles as shown on:
https://analysis.chromium.org/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtL2RiZmVkMjFmOTQ4ODFhMjkxODIyMzc5MmViZGUzNDc2YjhmZDY5ZTYM

Sample Failed Build: https://ci.chromium.org/b/8860163671563368608

Sample Failed Step: webkit_unit_tests

Original change's description:
> Fix several crashes when nested slots are removed from a ShadowRoot
>
> There were some crashes caused by nested slots (e.g.
> <slot><slot>Content</slot></slot>) being removed from the tree.
> These crashes were triggered by [1], which removed Shadow DOM v0, but
> my theory is that due to the old V0 shadow root code, more calls were
> being made to SlotAssignment::RecalcAssignment(). Now that the V0 code
> is gone, it has exposed some missing code.
>
> Three issues are being fixed here:
>  1. In Node::CheckSlotChange(), while removing the inner nested slot,
>     the parent_slot will have already been removed from the tree, so we
>     only need to call DidSlotChange if not. This used to be a DCHECK.
>  2. In TreeOrderedMap::Get(), while removing a key that previously had
>     more than one element, we may walk the tree and find that none of
>     the pre-existing elements are present. I.e. we're in a RemoveScope.
>     In this case, the key should be removed from the map.
>  3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can
>     just early-out if the slot isn't present in the map.
>
> I added a test for the crash conditions (variations on removing nested
> named and unnamed slots), plus I added a test for the TreeOrderedMap
> class, since there was none previously. The last test in the set
> documents the new Get() behavior. I also tried to improve some of the
> comments along the way. Finally, this CL rolls back a mitigation [2]
> previously landed for this crash.
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019
> [2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967
>
> Bug: 1159328, 1159727
> Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9
> Cq-Do-Not-Cancel-Tryjobs: true
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040
> Commit-Queue: Mason Freed <masonfreed@chromium.org>
> Reviewed-by: Yu Han <yuzhehan@chromium.org>
> Reviewed-by: Joey Arhar <jarhar@chromium.org>
> Auto-Submit: Mason Freed <masonfreed@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#838974}

Change-Id: I97202c545f74df090124e82775fe79ce978d3d63
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1159328, 1159727
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2601758
Cr-Commit-Position: refs/heads/master@{#839038}

…owRoot"

This is a reland of dbfed21f94881a2918223792ebde3476b8fd69e6

--> Patchset 2 contains the fix, just a missing initializer on an
int in the test.

Original change's description:
> Fix several crashes when nested slots are removed from a ShadowRoot
>
> There were some crashes caused by nested slots (e.g.
> <slot><slot>Content</slot></slot>) being removed from the tree.
> These crashes were triggered by [1], which removed Shadow DOM v0, but
> my theory is that due to the old V0 shadow root code, more calls were
> being made to SlotAssignment::RecalcAssignment(). Now that the V0 code
> is gone, it has exposed some missing code.
>
> Three issues are being fixed here:
>  1. In Node::CheckSlotChange(), while removing the inner nested slot,
>     the parent_slot will have already been removed from the tree, so we
>     only need to call DidSlotChange if not. This used to be a DCHECK.
>  2. In TreeOrderedMap::Get(), while removing a key that previously had
>     more than one element, we may walk the tree and find that none of
>     the pre-existing elements are present. I.e. we're in a RemoveScope.
>     In this case, the key should be removed from the map.
>  3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can
>     just early-out if the slot isn't present in the map.
>
> I added a test for the crash conditions (variations on removing nested
> named and unnamed slots), plus I added a test for the TreeOrderedMap
> class, since there was none previously. The last test in the set
> documents the new Get() behavior. I also tried to improve some of the
> comments along the way. Finally, this CL rolls back a mitigation [2]
> previously landed for this crash.
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019
> [2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967
>
> Bug: 1159328, 1159727
> Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9
> Cq-Do-Not-Cancel-Tryjobs: true
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040
> Commit-Queue: Mason Freed <masonfreed@chromium.org>
> Reviewed-by: Yu Han <yuzhehan@chromium.org>
> Reviewed-by: Joey Arhar <jarhar@chromium.org>
> Auto-Submit: Mason Freed <masonfreed@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#838974}

Bug: 1159328
Bug: 1159727
Change-Id: I0025c0f00d6b3876de8f40a60fdc34f726ddc85c
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2601051
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Yu Han <yuzhehan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#839148}

As per
https://github.com/web-platform-tests/rfcs/blob/master/rfcs/py_3.md,
step #2 of the transition to Python 3-only is to make 'wpt ...' commands
run in Python 3 by default.

Passing --py2 will now be necessary to run under Python 2. (Until ~Feb
2021, when we will remove py2 support entirely).

This does affect some CI runs. Cases where they already specified py3
will remain py3. Cases which are designed to run under py2 had `--py2`
added. Cases that didn't currently specify and aren't version specific
are upgraded from py2 to py3 (one example is Azure Pipelines Mac
infrastructure tests.)

Some Azure Pipelines helper scripts are used for both py2 and py3 tasks.
As a simple way to keep them working, `--py2` is used for them as it is
always available.

2 tests in this test suite seem inconsistent:

test#2 asserts that

tbody.height=10px > tr.height=1px > td.height=1px
implies td.offsetHeight = 1px

test#4 asserts that

tbody.height=10px > tr > td.height=1px
implies td.offsetHeight = 10px

Edge 17 is the only browser that agrees with #2 and web-platform-tests#4
FF agrees with #2, but not web-platform-tests#4
Chrome agrees with web-platform-tests#4, but not #2
Safari agrees with web-platform-tests#4, but not #2

To me, #2 and web-platform-tests#4 seem to be in conflict.
Either tbody height propagates to rows, or it does not.

The problem is that #2 is overconstrained.

My suggestion is that tbody height always propagates to tr.

Bug: 958381
Change-Id: I28bfd108c67968d31d0372b536c316c997d2d958
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2586097
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#845515}

…eb-platform-tests#28617)

Subresource Web Bundles.

The problem is: when Web Bundle fetching fails due to a network error,
Subresource fetch doesn't fail forever.
One such case (subresource-loading-cors-error test) was
timing out previously but passes successfully with this change.

This CL also adds 2 WPT tests:
1. subresource-loading-network-error.https.tentative.sub.html
2. subresource-loading-web-bundle-fetch-failed.https.tentative.html

Test #1 is a scenario with a different network error than the CORS
one, but with the same issue of subresource fetching timing out
without the change. It passes successfully after the change.

Test #2 is a scenario with a Web bundle not found error, which is
not directly influenced by the code added in this CL, but it expands
the test coverage which was found to be lacking the error cases before.

Bug: 1168449

Change-Id: Ia3abb967e36274becc86e317bc51b1272d3ae679
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2826001
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Miras Myrzakerey <myrzakereyms@google.com>
Cr-Commit-Position: refs/heads/master@{#875532}

Co-authored-by: Miras Myrzakerey <myrzakereyms@google.com>

1. Use GetWithoutInvalidation() instead of Get() in DCHECKs.
We should never call Get() inside of a DCHECK(), because this can
lead to a different code path depending on whether DCHECKs are enabled.

2. Get() should not cause immediate side effects. At most, it should
queue up an invalidation for later processing.

Fixing #1 and #2 were required in order to get past a first set of
errors introduced by the new test.

3. The actual fix -- avoid infinite loop by calling a special
new SlotAssignmentWillChange(), rather than ChildrenChanged(),
where a minimal GetWithoutInvalidation() is called that does not
lead to IsShadowContentRelevantForAccessibility() => FirstChild() =>
RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop).

A simpler potential fix is in CL:2965317 but requires more
research. It's also mentioned in a TODO comment.

Bug: 1219311
Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#892778}

This is a manual reland of
https://chromium-review.googlesource.com/c/chromium/src/+/3247449

The difference from the previous reland is that the browser tests now
include 2 separate timeouts and a double rAF, to ensure that the
presentation timestamp taken is far enough from both the time the first
frame is sent as well as from the time the second frame is sent.
More importantly, the test now actually is looking at the UKM metric,
rather than at the histogram.

Original change's description:
> [LCP] Add animated image support
>
> This CL adds support for better handling of animated images in LCP:
> * A new attribute is exposing the first animated frame's paint time
> (behind a flag).
> * `startTime` is not changed.
> * The PageLoadMetrics reported for LCP are set to that first frame paint
> time for animated images (behind another flag).
> * Entries are not emitted until the image is loaded.
>
> Relevant spec issue:
> w3c/largest-contentful-paint#83

Bug: 1260953
Change-Id: I34070bd90a74ed44281da63b547f13d9669f389b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3250690
Reviewed-by: Nicolás Peña Moreno <npm@chromium.org>
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#936516}

…rners

We had two issues:
1.  Before we had fast rounded corners, we always created mask layers
for rounded corner clips, and the mask layer made the scroll begin
unreliable and fall back to the main thread. With fast rounded corners,
the scrolls were treated as reliable without checking if the point is
in or out of the rounded corners.
2. If the scroller has a rounded corner by itself (instead of from an
ancestor), as we only create InnerBorderRadiusClip for the contents,
the compositor doesn't actually know which part of the layer bounds
is transparent to hit test (e.g. if the scroller has a border which
is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness,
such layers have HitTestOpaqueness::kMixed.

This CL changes the behavior of
LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from
FindLayerUpToFirstScrollableOrOpaqueToHitTest):
- For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the
  layer is affected by any fast rounded corners;
- For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only
  OpaqueToHitTest() (without checking IsScrollerOrScrollbar())
  because a hit test on a scrollable layer is reliable only if it's
  opaque to hit test.

Bug: 40277896
Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1291538}

Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use
the shadow tree of web-exposed shadow root, instead of using
light DOM elements of the host.

Bug #2: aRange could possibly create mCrossShadowBoundaryRange
first (due to boundaries are in different tree), and later
moves the boundaries to the same tree. When this happens, we
should remove mCrossShadowBoundaryRange and use the default
range to represent it.

Differential Revision: https://phabricator.services.mozilla.com/D207608

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783
gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f
gecko-reviewers: jjaschke, smaug, dom-core

Since @page border box layout objects aren't in the the layout tree, any
code that wants to walk up the tree to find the containing block will be
in for a surprise.

This would happen if percentage-based @page padding was used [1].
Recomputing padding during painting when we have already done it during
layout is rather pointless anyway. Read it out directly from the
fragment.

[1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent()
    #2 blink::LayoutBoxModelObject::ComputedCSSPadding()
    web-platform-tests#3 blink::LayoutBoxModelObject::PaddingTop()
    web-platform-tests#4 blink::LayoutBoxModelObject::PaddingOutsets()
    web-platform-tests#5 blink::BoxPainterBase::PaintFillLayer()
    web-platform-tests#6 blink::BoxPainterBase::PaintFillLayers()
    web-platform-tests#7 blink::BoxFragmentPainter::PaintBackground()

Bug: 40286153
Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}