1915976 - New wpt failures in /css/css-animations/parsing/ [animation-delay-computed.html, animation-iteration-count-computed.html]

Status: NEW

(Core :: CSS Transitions and Animations, defect)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Syncing wpt PR 47895 found new untriaged test failures in CI

Tests Affected

New Tests That Don't Pass

• /css/css-animations/parsing/animation-delay-computed.html [wpt.fyi]
  • Property animation-delay value 'calc(10s + (sign(2cqw - 10px) * 5s))': FAIL (Chrome: PASS, Safari: FAIL)
• /css/css-animations/parsing/animation-iteration-count-computed.html [wpt.fyi]
  • Property animation-iteration-count value 'calc(10 + (sign(2cqw - 10px) * 5))': FAIL (Chrome: PASS, Safari: FAIL)

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1915913 lands.

Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.

This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/

If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.

Comment 1

[Boris Chiou [:boris]]

It seems we got the incorrect result when using cqw in sign() and calc() for these properties.

Also, I notices there are a lot of related wpt failures.

Comment 2

[Boris Chiou [:boris]]

It seems like we got a parser error (i.e. CalcNode::resolve() returns an error) when using calc(10s + (sign(2cqw - 10px) * 5s)) on animation-delay. I will try to check what happened.

Comment 3

[Daniel Holbert [:dholbert] (PTO until 2/24)]

See also emilio's bug 1915980 comment 1. (All 6 of the bugs that are blocked-by bug 1915913 -- this one as well as that one -- seem to be essentially the same issue with sign(FOO - BAR) being rejected in various properties, where FOO and BAR are using different context-dependent units, which means the sign() expression can't be trivially resolved)