All of these tests current fail due to fuzzy upscaling/downscaling behavior,
which the tests aim to work around using `image-rendering: pixelated`, but we
don't yet support that feature. I've added the bug link for that feature to
these .ini files, so that we'll get a clue to remove these annotations once we
fix that bug and implement that feature.
Differential Revision: https://phabricator.services.mozilla.com/D40146
--HG--
extra : moz-landing-system : lando
Various cleanup:
- remove extraneous calls to grant_runtime_permissions
- remove unused legacy jimdb support code
- remove "This may take a while" logging
- emphasize x86/x86_64 capabilities of emulator
Differential Revision: https://phabricator.services.mozilla.com/D40302
--HG--
extra : moz-landing-system : lando
The animations of motion path are not running on the compositor, and the
properties in [motion-1] is not part of transform-like properties (i.e.
nsCSSProperties::TransformLikeProperties()) for now, so we should run
transform animations on the main thread if offset-path is not `none`.
Differential Revision: https://phabricator.services.mozilla.com/D39966
--HG--
extra : moz-landing-system : lando
We're hitting double imprecision here.
Example: Given 86.68392200000000 and 86.67999999999999 we want to see
if they're equal with two significant digits. (They are, they're 86.68)
However, when we reduce them, 86.68 (which is represented as an epislon lower)
gets reduced to 86.66 and they no longer match. We disable unconditional clamping
on these tests to confirm they behave the way they shoud... excepting the clamping
which may introduce imprecision.
Differential Revision: https://phabricator.services.mozilla.com/D38812
Depends on D38811
--HG--
extra : rebase_source : a437ead8c9ce69e6f34f81d69a924fefdbfec389
I believe these intermittents are caused by double imprecision. When unconditional clamping is enabled
it gets multiplied out and causes animation.currentTime to occasionally go to 50000.02 which causes
the test to fail. We can reduce the precision back down to ignore that. We do so using some WPT
overrides.
Differential Revision: https://phabricator.services.mozilla.com/D38810
Depends on D38809
--HG--
extra : rebase_source : 923172b3e7fd34458d6ee153ef33c0f830c954e3
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
Depends on D38806
--HG--
extra : rebase_source : d6f6170ae3082022d422f925e8d5619400e845ed
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
Make sure that deserializing an ActionSequence which misses the "id" field raises an "InvalidArgument" error.
Differential Revision: https://phabricator.services.mozilla.com/D39784
--HG--
extra : moz-landing-system : lando
We expect ColumnSet and -moz-column-content to be block outside.
If ColumnSets' display style is inherit from ColumnSetWrapper, then a
multicol with "display: inline-block" is going to wrap ColumnSet in a
inline nsLineBox when ColumnSet is added to ColumnSetWrapper, which is
not what we want.
This change fixed [.multicol 4] and [.multicol 6] in
multicol-gap-percentage-001.html with column-span disable, but it can
also fix [.multicol 5] in multicol-gap-percentage-001.html when
column-span is enabled (bug 1489298), so I go ahead and enable the pref
in that test.
Differential Revision: https://phabricator.services.mozilla.com/D39997
--HG--
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
Remove the pref dom.xhr.lowercase_header.enabled, as we are unaware of any actionable compat concerns now that bug 1540688 landed, and an ESR had been spun off.
Differential Revision: https://phabricator.services.mozilla.com/D39636
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
Update webxr_test_asserts and align xr layout_tests usage of asserts
Updates webxr_test_asserts with chromium's more verbose asserts for
easier debugging of tests, and removes the asserts from xr-test-utils
so that all asserts can be referenced from webxr_test_asserts.
Bug: 985156
Change-Id: Ie8d2ca70dd18a7e1759fe2b4d83b02076fcf91c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715916
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#680180}
--
wpt-commits: b94e0af56342652cf059d085758b0a229f3a38fb
wpt-pr: 18012
Automatic update from web-platform-tests
Fixing tranferFromimageBitmap-toBlob-offscreen.html to not be flaky
Replacing the getElementById by the creation of a new element to ensure
that the test will not be flaky.
Changing also the name of the function to be coherent with the test itself.
Bug: 978554
Change-Id: I8848b18f6d7f6201cce57069c5f4047d4d2f61e2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1693189
Commit-Queue: Juanmi Huertas <juanmihd@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#677456}
--
Fix promises in tranferFromImageBitmap-ToBlob-offscreen.html
The test previously used promises incorrectly:
testTransferFromImageBitmapToBlobOffscreen did not return the promise
produced by convertToBlob up to promise_test, which caused the assertion
(inside testCanvas) to flakiy escape promise_test. In addition, the test
did not wait for pngImage to load before drawing it to canvas.
This change also fixes the name of the test to be more accurate
(transferToBlob -> convertToBlob).
--
wpt-commits: 88a0c99744a4941af3907dfbb3853e3c23b00f04, 811dc186a0946a67e2b1ae59c0e92ccfeb69371d
wpt-pr: 17747
Automatic update from web-platform-tests
[LargestContentfulPaint] Add type to supportedEntryTypes
This CL adds 'largest-contentful-paint' to PerformanceObserver's
supportedEntryTypes, and adds a test. It also fixes a typo in the
LayoutShift supportedEntryTypes test title.
Bug: 965505
Change-Id: I6954f8abbdf27640413d790e05ff72aa945a248b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713295
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#680131}
--
wpt-commits: 2e53b93235999c9c9272859c2b2beadb96ef1f09
wpt-pr: 17975
Automatic update from web-platform-tests
Fix WebGLLayer test expectations
The xrWebGLLayer tests didn't have their expectations wrapped in t.step
so their failures were reported as timeouts, rather than the actual
error.
xrWebGLLayer_viewports expected the device init viewport to match the
output viewport, which is not a specced behavior, and contradicts the
webxr-test-api spec which calls this out as unsupported, so that part
has also been reverted.
Bug: 986672
Change-Id: I23713956f6b0bd3d432f0e6e6fdc9d015d509099
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715237
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/master@{#680125}
--
wpt-commits: 66cf52a5ffde8f409ebef4052ec0d1f30383875d
wpt-pr: 18004
Automatic update from web-platform-tests
[ElementTiming] Replace responseEnd with loadTime
This CL replaces responseEnd with loadTime in ElementTiming. Before,
responseEnd would be used and would be problematic for memory cached
images and for inline images (data scheme). We change it to loadTime,
the time at which LayoutObject::ImageNotifyFinished is called. This is
the same time as when LargestContentfulPaint computes loadTime. As they
are both under runtime flags and the hooks are not unified, for
simplicity we compute the timestamp again. This will not be too
expensive for ElementTiming, as the timestamp is gated on the existence
of the elementtiming attribute.
To store the loadTime, we change images_notified_ to be a HashMap which
now stores the timestamp corresponding to loadTime and whether the image
has painted (after being loaded).
Bug: 982046, 879270
Change-Id: I69da42c9250cc36c567df5da285ef1a9a357b554
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1710840
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#680117}
--
wpt-commits: 5275930d8392750a8d16934abc6c3f8f9802bcd6
wpt-pr: 17950
