Automatic update from web-platform-tests
Fix some view transitions crashtests (#45924)
They are currently written as reftests with reftest-wait and friends, convert them to use test-wait.
--
wpt-commits: 6ae7875d4162f8178de4bdce3da56887bce673e4
wpt-pr: 45924
Automatic update from web-platform-tests
Delete dragdrop_support.js from web platform tests.
The helper functions are redundant as they implement no extra logic.
So, removing these functions and replacing them by adding logs and
event listeners directly.
Bug: 336911513
Change-Id: Icebc99f432ff279c19cbe95e96143b9d67dbf67a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5487578
Commit-Queue: Kashish Jain <kashishjain@microsoft.com>
Reviewed-by: Sanket Joshi <sajos@microsoft.com>
Reviewed-by: Anupam Snigdha <snianu@microsoft.com>
Reviewed-by: Christine Hollingsworth <christinesm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293052}
--
wpt-commits: e29076d88b6749880683bc10817a0942ca61152b
wpt-pr: 45908
Automatic update from web-platform-tests
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}
--
wpt-commits: 3dad9a8b7f17fa61262de8713c6db4dac1c227c5
wpt-pr: 45776
Automatic update from web-platform-tests
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}
--
wpt-commits: 78d3bcd3bbe1d6989d4abed6b038546e07091520
wpt-pr: 45736
Automatic update from web-platform-tests
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}
--
wpt-commits: 4e4122e584b52d65fdb20b109ab72703dcca070f
wpt-pr: 45817
Automatic update from web-platform-tests
[aspect-ratio] Fix webm file that caused test flakiness
Test that uses this webm file started flaking when the file was changed
last month in
8bfc72a4f7
The linked chrome bug says the test is flaky on mac and fails on linux,
but flakiness dashboard shows it is actually flaky on all platforms on
the bots. See go/offqr
The test consistently fails on my local mac.
Simply re-encoding[1] the video with the vp9 version on my machine[2]
makes the test pass on chrome and doesn't regress on safari or firefox.
So give the re-encoded video a try?
The content of the video is not relevant to the test anyway, only the
dimensions of the video are relevant.
[1] ffmpeg -i support/2x2-green.webm -vf scale=iw*1:ih*1:flags=neighbor -c:v libvpx-vp9 -preset slow -crf 18 output.webm
[2] Lavc60.31.102 libvpx-vp9 instead of Lavc60.3.100 libvpx-vp9
Fixed: 333058973
Change-Id: If5f488b1bd4cbc16fec669dda682b8c2be97abfc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5492281
Auto-Submit: David Grogan <dgrogan@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292740}
--
wpt-commits: 514826504bc76f0d063d8758437b4c6e49b2785b
wpt-pr: 45920
Automatic update from web-platform-tests
[FedCM] Add more multi IDP WPTs
Add some WPTs for some common features like context and mediation. Also,
remove existing obsolete WPTs.
Fixed: 335897601
Change-Id: Ibed280eb0901564699d0d1f4041c3b2f5b311530
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5490962
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292689}
--
wpt-commits: da5b9d21f1111d8f787018440adc4bbd6529ccdc
wpt-pr: 45919
Automatic update from web-platform-tests
[css-flex] Include gaps in intrinsic sizes for column-wrap flexboxes
The intrinsic sizing code borrows PlaceFlexItems from Layout, but
PlaceFlexItems doesn't handle gaps, AlignFlexLines does. We don't want
to bring all of AlignFlexLines into intrinsic sizing, so just add gaps
manually.
Fixed: 335328452
Change-Id: Ic97b04ab22766a894299a3b74d0feea3734041fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5486047
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292562}
--
wpt-commits: 08418af6de2abeebc92b68bb423997ed3ba81029
wpt-pr: 45896
Automatic update from web-platform-tests
Move a prefers-color-scheme test to css/mediaqueries/ (#45887)
* Move a prefers-color-scheme test to css/mediaqueries/
Use the prefers-color-scheme.svg already in the target directory, and
adapt the test to use the blue/purple colors from that.
* Update prefers-color-scheme-svg-as-image-ref.html
--
wpt-commits: 4f1737843b28b72a0004133e6991a9741bca9b69
wpt-pr: 45887
Add one extra branch if we have before-change style but its display
is none, and the new style is not display:none. Also, we add an extra
subtest if we use the container query to change the display property.
Differential Revision: https://phabricator.services.mozilla.com/D208572
Now we use the starting style if we have, to replace the before-change
style. This includes a minor refactoring of the handling of transitions
because it becomes a little bit complicated.
Differential Revision: https://phabricator.services.mozilla.com/D208571
Per spec, we define starting style for an element as the after-change style
with @starting-style rules applied in addition.
If an element does not have a before-change style for a given style change
event, the starting style is used instead of the before-change style to
compare with the after-change style to start transitions.
The basic idea in this patch is:
1. We add a flag to indicate if this element may have starting style. We
set this flag during its full matching, and store this flag in the
element data.
2. So during process animations, we check this flag, if this element may
have starting style and specifies transitions, we resolve the
starting style. Use it as the before-change style.
The implmentation in process_animations() and tests are in the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D208570
The rules inside @starting-style doesn't apply to primary style, and
they are used only for CSS transitions (when computing starting style).
So adding a flag to make us easier to filter them out.
Differential Revision: https://phabricator.services.mozilla.com/D208569
