Bug 276664 – [css-transitions] WPT test css/css-transitions/starting-style-cascade.html has failures

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Antoine Quint]

If I look at https://wpt.fyi/results/css/css-transitions/starting-style-cascade.html, the latest STP (198 at the time of writing) is failing the final subtest "Starting style inheriting from parent's after-change style while ancestor is transitioning":

    FAIL message: assert_equals: Transition started from parent's after-change style color, inherited from ancestors after-change color expected "rgb(0, 192, 0)" but got "rgb(0, 160, 0)"

This subtest is not actually in our checkout, it was added a month ago in https://github.com/web-platform-tests/wpt/commit/401d9af978b784ad6d020ea8c17935ff01002525.

[Antoine Quint]

rdar://131515890

[Antoine Quint]

Antti fixed this for the parent-to-child case in 275061@main but inheritance doesn't work if intermediary elements don't have a transition or don't rely on @starting-style, it appears.

[Antoine Quint]

The issue appears to be that we don't set lastStyleChangeEvent() on elements that aren't animated. Yet, we need this to obtain the after-style change event on the non-animated parent element in the failing test.

[Antoine Quint]

No, that's not the issue. In this case the intermediary, non-animated <div> has its last style change event style set, but the issue is that it contains the inherited value from the parent which matches the current animated state, not the final state of the transition. We somehow need to be able to reconstitute that value.

[Antoine Quint]

Perhaps what we need to do here is not to use the `resolvedStyle.style` as the style to store as the last style change event style in Style::TreeResolver::createAnimatedElementUpdate(), but rather create that style by inheriting from the parent's last style change event style. That way the last style change event style would become the after-change style. We'll have to see whether that causes regression. We may have to store both otherwise, but I worry this could cause a perf or memory regression.

[Antoine Quint]

I got it to work quickly, and it does work. My current work-in-progress patch breaks a host of pseudo-element-related tests, so I'll need to figure this out first and then see if we need to introduce the notion of an after-change style on top of the last style change event style.

[Antoine Quint]

I made good progress on this in https://github.com/graouts/WebKit/tree/after-change-style but have not got something working without regressing other tests. I'll resume work on this later in August.

[Antoine Quint]

The failing test is being imported in bug 279058.

[Antti Koivisto]

Pull request: https://github.com/WebKit/WebKit/pull/33382

[EWS]

Committed 283423@main (826e5996a267): <https://commits.webkit.org/283423@main>

Reviewed commits have been landed. Closing PR #33382 and removing active labels.

[EWS]

Committed 283286.13@safari-7620-branch (1c106d4bb45e): <https://commits.webkit.org/283286.13@safari-7620-branch>

Reviewed commits have been landed. Closing PR #1727 and removing active labels.