1941651 - Crash during CSS Animation with display: var(--disp), where the --disp variable is animated to & from 'none'

Status: RESOLVED FIXED

(Core :: CSS Transitions and Animations, defect, P2)

Description

[Max]

Attachment: Example code that triggers the crash.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0
Firefox for Android

Steps to reproduce:

1. Create a HTML document, with a grid of 3 rows.
2. Add 6 children.
3. Create two variables on the CSS grid property: one for the first three children, one for the last three children. Set the value to "grid".
4. Set the display property of the first and last children equal to the corresponding variable value.
5. Create an animation, that changes the first children's variable to "none".
6. Open this document in Firefox, either the desktop or Android version.

Actual results:

Firefox starts to play the animation, but the webpage crashes and Firefox informs you it crashed.

Expected results:

The animation should have played, with no crash or hiccup.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Donal Meehan [:dmeehan]]

:dshin example here still causes a crash even after Bug 1940212 was fixed

Comment 3

[Alice0775 White]

bp-aaddf265-f02c-4565-85b9-df8110250114

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a crash signature, thus the bug will be considered confirmed.

Comment 5

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case

This seems unrelated to bug 1940212. Minimized case that is non-crashing but nevertheless showing behavioural difference between Gecko, Blink and WebKit attached. The purple div briefly blinks on Firefox. Looking at devtools, I see animations existing for a fraction of a second, then being removed, as if no animation is specified. On Safari Technology Preview, the div disappears and stays gone. On Chrome, the div behaves as author intended.

The root cause seems to be that we are ending up animating display here. It's not animatable. In fact, replacing --disp with display result in a static purple div across the 3 browsers.

Overall, this seems like a side-effect of animatable custom properties being applied to display.

Comment 6

[Max]

Thank you, this pointed me to using position: absolute and visibility: none instead of display: none, as discussed here. This works with no issues.

Comment 7

[David Shin[:dshin]]

Attachment: Fixed Minimum Reproducible Case

Oops, attached testcase was in a wrong state that proves that display is non-animatable. Here's the version that shows discrepancy with custom properties.

(See also bug seems to indicate that we resolved to avoid this behaviour, but didn't it didn't make it to all browsers, I believe)

Comment 8

[Emilio Cobos Álvarez [:emilio]]

We should still not crash tho. We're not supposed to find unstyled elements during frame construction.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 11

[Daniel Holbert [:dholbert]]

(clarifying summary to remove grid and mention css variables, based on the reduced testcase in comment 7 here.)

Comment 12

[Boris Chiou [:boris]]

Attachment: Reduced testcase (2025/2/11 build)

I cannot reproduce this with these two minimum cases on my mac in Nightly today, so I updated the reduced testcase from the example again.

Comment 13

[Boris Chiou [:boris]]

(In reply to David Shin[:dshin] from comment #5)

The root cause seems to be that we are ending up animating display here. It's not animatable. In fact, replacing --disp with display result in a static purple div across the 3 browsers.

Overall, this seems like a side-effect of animatable custom properties being applied to display.

Right. display property is not ready to be discrete animatable, so in this case it accidentally runs a discrete animation there I guess.

We may have to prevent it from running any animations on the non-animatable properties when using custom variables.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1941651 - Relax a bit the requirements of animation-only traversals. r=#style,boris,hiro

The whole animation-only traversal thing is quite messy, but it can
generally no longer assert that it only deals with already-styled
subtrees, since we want to make display animatable.

Make it more in line with the regular traversal, in order not to leave
the tree in an inconsistent state (an element with display != none that
has unstyled children), which the frame constructor complains about
(rightfully so).

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52430cf39095
Relax a bit the requirements of animation-only traversals. r=dshin

Comment 16

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

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51096 for changes under testing/web-platform/tests

Comment 17

[amarc]

https://hg.mozilla.org/mozilla-central/rev/52430cf39095

Comment 18

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

Upstream PR merged by moz-wptsync-bot