Automatic update from web-platform-tests
Send automatic beacons to all registered URLs.
Previously, automatic beacons would only send to destinations that were
explicitly specified when calling setReportEventDataForAutomaticBeacons.
That means that if the call did not specify a destination, but the
worklet for that destination registered an automatic beacon through
registerAdBeacon(), that destination would not get a beacon.
Any destination that asked to receive a beacon for a top-level
navigation has a vested interest in knowing if a something happened
based on a click. The frame that calls
setReportEventDataForAutomaticBeacons() should not be allowed to
interfere with whether a destination gets that information. However,
that frame should still have control over what destinations get the data
it’s setting for the automatic beacon.
This CL modifies that behavior so that if the above case happens, the
destination will now get sent an automatic beacon, but the automatic
beacon data will not be included in the payload. This will allow for
all top-level navigation events to notify every endpoint that wants to
be notified, but still give the frame control over who gets access to
the actual data.
As part of this change, the "once" parameter will now determine whether
the beacon data is sent once/multiple times, rather than the old
behavior of it determining if the beacon itself is sent once/multiple
times.
This change is gated behind the "FencedFramesM119Features" flag.
This CL also updates web platform tests and some fenced frame browser
tests to enable the "FencedFramesM119Features" flag, allowing for
testing this change.
See doc: https://docs.google.com/document/d/1vLifppH8TC86sl4kbam57egttqb4VNwEkVvZdefGIuQ/edit?usp=sharing
Change-Id: Iba4f4d56b2f5a2162cde2d3546c208f70dfd1abd
Bug: 1482328
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4860420
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200208}
--
wpt-commits: 8c3ce244dc3619f1205dbcf53fb2e9a8d56d4201
wpt-pr: 41988
Automatic update from web-platform-tests
Clamp out-of-gamut legacy rgb values
Previously legacy rgb color parameters were clamped to [0, 1] (which
is serialized to [0, 255], for legacy reasons) at parse time.
Refactoring the color parser overlooked this, as serialization did
the clamping. This lead to a corner case where out-of-gamut values
could be parsed and stored, and would be serialized as normal. The
out-of-gamut stored values will interact with alpha blending, causing
alpha to seem higher than it is (see bug).
See https://chromium-review.googlesource.com/c/chromium/src/+/4879797
to confirm that the regression test is working as expected.
I removed Color::IsLegacyColor() in favor of
Color::IsLegacyColorSpace(Color::ColorSpace) because they both do
exactly the same thing and the latter is slightly more useful.
I also took out the logic to take care of non-finite values in
serialization of legacy colors as the spec is now explicit that they
should be clamped.
css1/units/color_units.html is an invalid test that was never meant to
have an image baseline. This is made clear if you read the text within
said test. The reason it is failing for this CL is because it was
expecting the very behavior that caused the bug in crbug.com/1483736.
The new test out-of-gamut-legacy-rgb.html verifies this much more
clearly. The image output also only renders half of the page. It is
merely meant to validate that different color inputs should be
rendered the same way within the page. This is already well tested in
WPT, for example:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/css/css-color/rgb-001.htmlhttps://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/css/css-color/rgb-002.html
All that stated, I think this test is slowing down development and not
providing any value, so I deleted it. The fact that it already had
four different baselines was a good sign that it was just blindly
being rebaselined.
Bug: 1483736
Change-Id: Ibb707f29638356bb0835903e6a56b73ad0969496
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878299
Commit-Queue: Aaron Krajeski <aaronhk@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200189}
--
wpt-commits: 8bb6f00a4893963f3f9a03d64bfaeaca9de76f66
wpt-pr: 42084
Automatic update from web-platform-tests
Set original error as context when raising a different error
--
wpt-commits: 5f0fba3215492e89b9021bf3bfb9dac63e8fd7c9
wpt-pr: 42116
Automatic update from web-platform-tests
Add async condition support to step_wait_func
Allow async condition function in step_wait_func. We'll be able to
write something like:
```js
await step_wait(async () => (await fetch(url)).status === 200);
```
--
wpt-commits: 29ec88973978322a6d0e85f8bdc88522408d3948
wpt-pr: 34289
Automatic update from web-platform-tests
webrtc wpt: add tests related to two-byte RTP header extensions
which can exceed the 1-14 range.
The id 15 is checked for explicitly since it is disallowed by one-byte
header extensions
https://www.rfc-editor.org/rfc/rfc8285#section-4.2
but should be supported otherwise.
Note that this is a grey area, neither RFC 8285 nor RFC 8834 explicitly
mandate support for two-byte extensions.
BUG=chromium:1051821
Change-Id: I8c521e07c9844447e289b31fcd7d8c3341e5e050
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4847027
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200120}
--
wpt-commits: 02562afc3408c8c11a12312e9cc503548df21367
wpt-pr: 41843
Automatic update from web-platform-tests
Add a 'required' field to taskcluster tasks
Tasks with 'required' set to False will not affect the outcome of the
sink task. This allows taskcluster tasks to be added which do not
block CI / only act as warnings.
--
Mark Chrome stability task as not required
As per RFC 131:
https://github.com/web-platform-tests/rfcs/blob/master/rfcs/disable_chrome_stability.md
--
wpt-commits: a1fa1e958cb0f1d39b73a7b12776e1da76d76a24, 522c19491fe5ae6b6d609e5a6acede7142fac90c
wpt-pr: 41936
Automatic update from web-platform-tests
Ensure everywhere we log a traceback it says where it is from
Otherwise we end up with arbitrary tracebacks which are unclear as to
where they're being logged from
--
wpt-commits: f7a3451e8413389e9fc24d6d2e28aa1e08d512a6
wpt-pr: 42004
Automatic update from web-platform-tests
[text-spacing-trim] Support fonts with `chws`
This patch changes the `EastAsianSpacing` logic to support
fonts with `chws`, along with a test with a test font that
has `chws`.
When the font has `chws`, it can handle character sequences
automatically, similar to kerning. All what the rendering
engine must do is at the run edges, where OpenType features
can't handle.
Not only necessary, applying `halt` on top of `chws` kerns
twice, causing glyph collisions. This patch fixes it.
The test is the same as `text-spacing-trim-001.html` except
it uses the font with `chws`. This can probably be done by the
wpt variants[1], but it doesn't work as expected with Chromium
bots. This is being investigated separately[2].
[1] https://wpt-docs.readthedocs.io/en/latest/_writing-tests/testharness.html#variants
[2] crbug.com/1485860
Bug: 1463891
Change-Id: Ia8d8fd260135b43cdcd3b266ca1de038d22809b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4881743
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200102}
--
wpt-commits: 9fed32c6cef0022c32812e67c59ee399237f3ecb
wpt-pr: 42115
Automatic update from web-platform-tests
[text-spacing-trim] Add a test font that has `halt`
This patch adds a test font that has `halt` and `vhal`, but
not `chws` nor `vchw`. This patch also adds tests using the
font.
The plan is to do these things in following patches:
* Add a test font with `chws` and `vchw`.
* Use these fonts in existing tests for `text-spacing-trim`.
* Fix issues if any are found in these tests.
Note, a subset of Noto Sans CJK already exists in
`/wpt/css/css-fonts/resources`, but this is a different
subset, both in code points and in features.
Bug: 1463891
Change-Id: Ib7df3bfaac44be822cf2c7f96cdc83f935865738
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4881965
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Commit-Queue: Lingqi Chi <lingqi@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Auto-Submit: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1200069}
--
wpt-commits: ba70881d5cc75412640c5b96f50d3c65a00ec4b8
wpt-pr: 42107
Automatic update from web-platform-tests
WebKit export: CSS <position> should never serialize to a single value (#42112)
https://bugs.webkit.org/show_bug.cgi?id=258585
--
wpt-commits: 2985a9997f18b83a9cd48d32b2d46b3b38f0bcb8
wpt-pr: 42112
Automatic update from web-platform-tests
Make sure fixed-length getComputedStyle() inset values roundtrip
Since crrev.com/c/4583533, when we try to get an inset value from an
absolutely positioned box, we always get it from the layout result.
This caused some rounding errors, since layout and CSS values have
different precisions. And this is unexpected to some sites.
This patch makes sure that we directly return result from the computed
style in simple cases (fixed-length values without position fallback
complications), so that the result roundtrips and avoids the rounding
difference.
Fixed: 1482703
Change-Id: I7ee97824ace2b23c81c687c347f63d24d8b72531
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4881119
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Auto-Submit: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199941}
--
wpt-commits: 5c64599f92f5672c2b96c3f8acf1111af37782f2
wpt-pr: 42097
Automatic update from web-platform-tests
scroll-to: Improve handling for invalid percent encoding
https://github.com/WICG/scroll-to-text-fragment/issues/229 pointed out
that percent encoding in the spec didn't restrict to just two
hex-digits. That was fixed in the spec so this CL ensures malformed
percent-encodings in a text-directve cause the directive to be invalid.
Bug: 1482847
Change-Id: If4c0b8918b355d644d31742c08b92b5c6da59318
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4874539
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199827}
--
wpt-commits: fd5c6b67384e849eab4b96d8caff892e461e199a
wpt-pr: 42032
Automatic update from web-platform-tests
Fix css/css-transforms/transform-2d-getComputedStyle-001.html
According to https://github.com/w3c/csswg-drafts/issues/9121, there is
no full consensus on the resolved value of transform on an element
with 'display: none', and for now we should accept both 'none' and
the value not depending on 'display'
(https://github.com/w3c/csswg-drafts/issues/9121#issuecomment-1683001516).
Bug: 1418705
Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199807}
--
wpt-commits: 86693b117d3f2179ec1714c0566736945d445322
wpt-pr: 42092
Automatic update from web-platform-tests
Include more in sysdiagnoses on macOS
Try and get further with https://github.com/web-platform-tests/wpt/issues/41386
--
wpt-commits: a44cc1a0dda0b708e507a557d3fdde241c253b00
wpt-pr: 42108
Automatic update from web-platform-tests
Fix all-with-discrete transition test
Issues with the test:
* TransitionStart was being tested before confirming that the
animation was ready. The timing of when the animation is ready is
UA dependent.
* Waiting a single frame after starting the animation ensures the
transtionstart event is queued, but event dispatch could be in the
next frame
We can avoid the timing nuances by simply querying all animations.
The query itself forces a style update. The animation will be in
a play-pending state at this point so the transitionstart has not
had a chance to fire; however, we can verify that the animation is
a CSSTransition for the expected property.
This test still fails on Firefox, but that is due to not supporting
"allow-discrete". The test passes reliably in Chrome.
Bug: 1477833
Change-Id: I4360d7f66e25b5026a17d332a8f6a3af7482d2dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4880561
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199763}
--
wpt-commits: 6e5d0de739160bf99505eea5381a1981f913a323
wpt-pr: 42105
Automatic update from web-platform-tests
Add drop-shadow() currentcolor test for filter on SVG content
Based on css/filter-effects/drop-shadow-currentcolor-dynamic-001.html,
but with content updated to have the filter apply on SVG.
Bug: 1469327
Change-Id: I2b389c56c37f59fa50e8ee3ee2a8364cbab91fe0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4882597
Auto-Submit: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199653}
--
wpt-commits: 983ffcf78c4693a9abf7f8d701406f226f20ebcb
wpt-pr: 42102
Automatic update from web-platform-tests
FSA: Reset mojo pipe on encountering any WritableFileStream error
The lock should be released when the stream enters an ERRORED or
CLOSED state, otherwise errored streams may hold locks until the
stream is garbage-collected.
Bug: 1380650
Change-Id: I33ca22ffcb58cbc04c87e410bb356c8697c57900
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492276
Reviewed-by: Daseul Lee <dslee@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199652}
--
wpt-commits: 88263fb2b740d44a8fcb8fc3a2800c34331502de
wpt-pr: 42086
Automatic update from web-platform-tests
Rewrite (behind a flag) HTML direction inheritance and invalidation for dir=auto
This rewrites significant aspects of inheritance of HTML direction
(which affects the unshipped :dir() selector and also the shipped
dirname attribute), including its invalidation, to match current spec
proposals regarding how the inheritance operates on Shadow DOM, and to
improve invalidation in response to dynamic changes. Inheritance of
direction now operates on the node tree, except that shadow roots and
slots both inherit from the shadow host. It previously operated on the
flat tree. This change should not affect the computed values of the CSS
direction property, since the HTML direction is only mapped to CSS
direction on elements where the HTML direction is not inherited.
This also restructures the shadow tree-related invalidation code for
dir=auto to match the changes implemented in
https://crrev.com/26b1b30268b7af4f0e44f298c10338a65e656f40 , which made
dir=auto operate on the node tree, and the additional behavior
implemented in
https://crrev.com/6abc9cbde67c0700be364c7aab86cb29188c7d5d that
implemented special rules (looking at slotted children) for <slot
dir=auto>. Certain text-like form controls also have similar special
rules in which they look at their value. This change can affect the
computed values of the CSS direction property when the direction
computed by dir=auto is different.
The invalidation code for these two distinct things was (in the old
code) too tied together to cleanly separate these changes.
The reason these changes are the next step of work is because they
change (when CSSPseudoDirEnabled) the one caller that passed a
stay_within parameter to CalculateAndAdjustAutoDirectionality that is
different from this; this enables further (smaller) refactoring that I
believe will be needed to fix the failure of
external/wpt/shadow-dom/directionality/dir-shadow-41.html in the
still-unlanded WPT PR at
https://github.com/web-platform-tests/wpt/pull/29820 . I believe this
existing using of stay_within does not make sense; it doesn't make sense
to try to partially traverse the descendants of a dir=auto element with
a different termination point. The traversal of a dir=auto element
should always start at its start and should terminate at the first
strong character or the end of the contents that should influence the
dir=auto. (There are cases where the interaction of the stay_within and
the use of NodeTraversal/FlatTreeTraversal meant that the stay_within
parameter was missed entirely and the tree was searched beyond the
contents that should be; this is a step towards the refactoring needed
to fix that.)
This is based on the proposed behavior described in:
https://github.com/whatwg/html/issues/3699#issuecomment-951423468
which is in the process of being specified in:
https://github.com/whatwg/html/pull/9166https://github.com/whatwg/html/pull/9452https://github.com/whatwg/html/pull/9554
Bug: 576815
Change-Id: Ic31a3f801f64042a3b4979afdc4e141f45e3b228
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4811757
Reviewed-by: Di Zhang <dizhangg@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199647}
--
wpt-commits: ce9459e524221bf8f2b7ba04bc21af109a89eb14
wpt-pr: 42030
Automatic update from web-platform-tests
Fix tests and expectations for css counters
Without <span>s tests don't match the reference on Mac.
Some symbols are generated slightly shifted due to the pixel snapping
when the words are wrapped in spans.
Bug: 990657
Change-Id: I25b00aecfc9c3311847ebcdef185aedebc55a2b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4874018
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Daniil Sakhapov <sakhapov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199611}
--
wpt-commits: 98a8e0b28f6eba41b3bc408ac93905c756a15f48
wpt-pr: 42027
Automatic update from web-platform-tests
[task-attribution] Reland: Move to an implicit GCed task container model
The current task_container_ is a circular buffer with limited space.
That limits the potential use cases for TaskAttribution, and adds
needless complexity. This CL significantly simplifies that model, by
moving the container to be implicit, and relying on GC to clean up tasks
once they are no longer needed - that is, once all their descendent
tasks were done and evicted.
This is a reland of [1], that moves the MessagePort destructor work to
a prefinalizer, to avoid invalid memory reads during destruction.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/4614509
Change-Id: I2d61092f96cfd8207ca899c81c15ac808f094300
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4831380
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199538}
--
wpt-commits: 15c5dda9f66b9e43ebde373e1669ccbf8145b486
wpt-pr: 41746
Automatic update from web-platform-tests
HTML: align XHR URL encoding expectations with the specification
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-open never said UTF-8 it seems like.
--
wpt-commits: 2cd449b9df6f92862abac0143ac6fe674fd5278e
wpt-pr: 42049
Automatic update from web-platform-tests
Deflake (another) MediaStreamTrack-video-stats.https.html test.
The test asserts that a clone discarding frames does not affect the
discardedFrames counter of the original track (despite sharing the same
source, just having different VideoTrackAdapters).
The test used different non-zero discard rates and then did an
assert_approx_equals before and after cloning. However because slow
bots can have widely varying frame rates and discard rates, this
assertion was flaky (even at approx comparison of +/- 5).
To deflake, this CL simplifies things by having the original track's
discard rate be 0 and asserting that after the clone is created the
total discardedFrames count is still 0. This should never flake.
Bug: chromium:1484719
Change-Id: Ifa71838d3db07fd6a498580a17985baebd85aed7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4882477
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
Auto-Submit: Henrik Boström <hbos@chromium.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199470}
--
wpt-commits: c641887deeae9a3ef1e177a1380a448e8ee3ccf7
wpt-pr: 42099
Automatic update from web-platform-tests
Implement form-sizing behavior for <textarea> and text <input>
Their auto sizes depend on its text values and placeholders.
* layout_box.cc: Don't provide default intrinsic sizes
* NGBlockLayoutAlgorithm::ComputeMinMaxSizes():
The placeholder box should contribute to
MinMaxSizes.
* NGBlockLayoutAlgorithm::Layout():
HandleTextControlPlaceholder() can update the content block size.
* NGBlockLayoutAlgorithm::HandleTextControlPlaceholder():
If the placeholder box is taller than the text box, returns the
block end offset of the placeholder box.
FinishTextControlPlaceholder() is a helper for this behavior.
Bug: 1447058
Change-Id: Ia4d6a687edc715ad8574aee79cca862e113cc9f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4835842
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199414}
--
wpt-commits: f8b45b803f788789e949b6657eb6e4e5f9f287e2
wpt-pr: 41999
moz-wptsync-bot
Liam Brady
Tim Nguyen
Aaron Krajeski
James Graham
dependabot[bot]
Yutaka Hirano
Philipp Hancke
wpt-pr-bot
Sam Sneddon
Koji Ishii
Yi Xu
Tianyang Xu
Xiaocheng Hu
Mike Jackson
Gerald Squelart
Stephen McGruer
David Bokan
Xianzhu Wang
Kevin Ellis
Fredrik Söderquist
Austin Sullivan
L. David Baron
Yoav Weiss
Daniil Sakhapov
jrandolf
Anne van Kesteren
Henrik Boström
Kent Tamura