Releases · web-platform-tests/wpt

26 Apr 12:00

5ae7513

merge_pr_45880

Bump mozrunner version to 8.3.1.

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

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1893190
gecko-commit: b743d99059effb91581a29dcf6595a01d5c1716d
gecko-reviewers: perftest-reviewers, jgraham, sparky

Assets 8

26 Apr 12:16

github-actions

merge_pr_45871

2041b49

merge_pr_45871

webnn: Migrate slice validation tests to WPTs

This CL adds WPT tests for slice and removes the unit tests
MLGraphBuilderTest.SliceTest, MLGraphTestMojo.SliceTest and
MLGraphTest.SliceTest.

Bug: 327337526, 328026885
Change-Id: I1774d86972d6ab0a02080d9f36d1ce939bea69f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5481673
Commit-Queue: Shanxing Mei shanxing.mei@intel.com
Reviewed-by: ningxin hu ningxin.hu@intel.com
Reviewed-by: Austin Sullivan asully@chromium.org
Cr-Commit-Position: refs/heads/main@{#1292942}

Assets 8

26 Apr 12:38

github-actions

merge_pr_45859

528d480

merge_pr_45859

Bump types-setuptools from 69.5.0.20240415 to 69.5.0.20240423 in /tools

Bumps types-setuptools from 69.5.0.20240415 to 69.5.0.20240423.

Commits

updated-dependencies:

dependency-name: types-setuptools
dependency-type: direct:production
update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] support@github.com

Assets 8

26 Apr 13:34

github-actions

merge_pr_45820

c6269c3

merge_pr_45820

Add Ahem font to allow list when installed by wptrunner.

This also renames the white list variables in the associated test files to allow
list. The pref name is not so straight forward to change.

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

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1892399
gecko-commit: c889e3972268157ead34b8a9af88bd8e95b2ea74
gecko-reviewers: jgraham

Assets 8

26 Apr 03:07

github-actions

merge_pr_45817

4e4122e

merge_pr_45817

webnn: add IDL and mojo definition of gelu operator

This CL also adds validation tests in WPTs and a unit test
WebNNGraphImplTest.GeluTest.

Bug: 40206287
Change-Id: Ia197fa637e036e73c4e7d5e832685364633c0384
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5470161
Commit-Queue: Shiyi Zou shiyi.zou@intel.com
Reviewed-by: Alex Gough ajgo@chromium.org
Reviewed-by: ningxin hu ningxin.hu@intel.com
Auto-Submit: Shiyi Zou shiyi.zou@intel.com
Reviewed-by: Austin Sullivan asully@chromium.org
Cr-Commit-Position: refs/heads/main@{#1292836}

Assets 8

26 Apr 14:54

github-actions

merge_pr_45776

3dad9a8

merge_pr_45776

Make setting defaultValue from a trusted input event validate

This adds a large-ish test of the validation behavior of the
textarea element, which as far as I can tell is under-specified,
or at least I could not find this behavior in the spec. I looked
mainly here:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#validity-states

In particular, there are some interesting differences in the
validity of initially-empty vs initially-non-empty textareas.

This CL, though, also aligns the behavior of Chromium with both
WebKit and Gecko in the specific case where the input event
handler sets textarea.defaultValue. In that case, the textarea
will be validated correctly. Previous to this CL, Chromium would
not validate the textarea as a result of the change.

Fixed: 333940413
Change-Id: Iec38fb510296d34419b7ed3df8ab396d2d737d69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5463568
Auto-Submit: Mason Freed masonf@chromium.org
Reviewed-by: David Baron dbaron@chromium.org
Commit-Queue: David Baron dbaron@chromium.org
Cr-Commit-Position: refs/heads/main@{#1293030}

Assets 8

26 Apr 09:33

github-actions

merge_pr_45736

78d3bcd

merge_pr_45736

Plumbing for new pagination fragment structure.

Previously each page would be represented by a single page fragment
(fragmentainer) with all the document contents inside. However, in order
to support @page properties and margins, we need something more
advanced.

Split the page fragment into three fragments: page container, page
border box, and page area. A page area will always be a child of a page
border box, which in turn will always be a child of a page container.
Page containers are direct children of the LayoutView fragment.

A page container will represent the containing block of a page. It
represents the entire sheet of paper (when printing one page per sheet).

A page border box is simply the border box size of a page. It will be
responsible for painting any effects caused by @page properties - except
the background, which should cover the entire page container.

A page area is a fragmentainer. It contains a portion of the fragmented
document.

See https://drafts.csswg.org/css-page-3/#page-model

For now, all these fragments have the same size, since margins are still
handled on the outside of Blink (e.g. printing::PrintRenderFrameHelper).
This will change in upcoming CLs.

In order for these new fragments to be able to paint anything, they need
a BlockNode (LayoutObject). A BlockNode will also be required in order
to resolve lengths in the standard way, using length_utils (upcoming
CL). These layout objects will not be attached to the layout tree (i.e.
under the LayoutView), since we cannot mutate the layout tree during
layout, and besides they wouldn't serve any purpose there. Such layout
objects are "owned" the new PaginationState class, and destroyed when
the pagination layout fragment tree is no longer needed.

The page area serves as a boundary between the document's contents and
the (non-DOM) page boxes. Therefore, don't propagate info from a page
area fragment to its parent (page border box) fragment. They will
eventually exist in different coordinate systems. OutOfFlowLayoutPart
needs to be updated because of this. Out-of-flow layout needs to take
place when we have returned to the root algorithm. OutOfFlowLayoutPart
now needs to grab any pending OOFs manually from each fragmentainer
(page area inside page border box inside page container), and lay them
out.

No behavior changes intended, unless PageMarginBoxes are enabled.
Keep on reading. We're almost done.

When PageMarginBoxes are enabled, any @page properties that are to apply
in a page context according to the spec may now have paint effects.
@page borders for instance. Add a test for that. Note that layout still
doesn't position the page area correctly within the page border box,
which is why the text in the test is centered (if it were positioned at
0,0, it would have been painted over the border). StyleResolver needs to
be adjusted, to make sure that initial style is returned if the page
context is inside a display:none subtree (an existing test would fail if
not). If computed style is to be generated, on the other hand, make sure
that it becomes display:block.

Bug: 40286153
Change-Id: I59b088bcdde3d95782358809f2377cd61e6a1f73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5453623
Reviewed-by: Ian Kilpatrick ikilpatrick@chromium.org
Commit-Queue: Morten Stenshorne mstensho@chromium.org
Cr-Commit-Position: refs/heads/main@{#1292911}