CSS animations break in details tags
Categories
(Core :: CSS Transitions and Animations, defect, P3)
Tracking
()
People
(Reporter: andreas.lundblad, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
417 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
This CSS animation fails after collapsing / expanding details tag
<html>
<head>
<style>
@keyframes colorchange {
from { color: red; }
to { color: blue; }
}
</style>
</head>
<body>
<details>
<summary>Animation</summary>
<span style="animation: colorchange 1s linear 0s infinite;">Hello World</span>
</details>
</body>
</html>
Actual results:
Animation not running after expand/collapse/expand
Expected results:
The animation should run. (As it does in google chrome for example.)
|
||
Updated•5 years ago
|
|
|
||
Comment 1•5 years ago
|
||
I can reproduce the problem on Nightly69.0a1 Windows10.
|
|
||
Comment 2•5 years ago
|
||
|
||
Comment 3•5 years ago
|
||
Thanks Alice!
Huh, this is a weird one. I was surprised that we didn't have any test for something like this, but this is pretty specific to <details>, that is, it doesn't repro with:
<!doctype html>
<style>
@keyframes colorchange {
from { color: red; }
to { color: blue; }
}
</style>
<button onclick="this.nextElementSibling.toggleAttribute('hidden')">Toggle</button>
<div>
<span style="animation: colorchange 1s linear 0s infinite;">Hello World</span>
</div>
So I think this is an issue with the way we implement <details>. In particular, elements in <details> aren't hidden via display, but via this code:
I suspect that this causes the animation to stop in StopAnimationsForElementsWithoutFrames.
But then the style system has no way to re-start the animation, I think...
As of how to fix this, I suspect we could:
-
Try to remove the StopAnimationsForElementsWithoutFrames code. I don't know why it'd be needed these days since the style system takes care of the animations on its own. I guess it'd be slightly inefficient in this case, since we wouldn't stop the animation.
-
Rewrite
<details>to use a proper shadow tree now that we support Shadow DOM. This should make it use less magic and this should automatically work, I'd think. -
Make the restyle manager restart animations when an element that didn't have a frame because it was suppressed gains a frame. This seems pretty hard to detect to me, off-hand.
|
||
Comment 4•5 years ago
•
|
||
I thought we restart the animation after reconstructing the frame. I should check how it works again. :O
Thanks, Emilio.
|
|
||
Comment 5•5 years ago
|
||
(In reply to Boris Chiou [:boris] from comment #4)
I thought we restart the animation after reconstructing the frame. I should check how it works again. :O
Thanks, Emilio.
Well, we start animations after we get a new style (https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/servo/components/style/matching.rs#332), but that doesn't help in this case, since there's no new style at all, the frame is suppressed in a different way.
|
|
||
Comment 6•5 years ago
|
||
I spent some time today on bug 1308080, which fixes this, if we want to go that route.
|
|
||
Updated•5 years ago
|
|
||
Comment 7•5 years ago
|
||
- Try to remove the StopAnimationsForElementsWithoutFrames code. I don't know why it'd be needed these days since the style system takes care of the animations on its own. I guess it'd be slightly inefficient in this case, since we wouldn't stop the animation.
Whether or not the animation is stopped is observable since we need to dispatch an animationcancel event and update the corresponding CSSAnimation object once the animation enters a display:none tree (and there are wpt for this).
|
|
||
Comment 8•5 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #7)
Whether or not the animation is stopped is observable since we need to dispatch an
animationcancelevent and update the correspondingCSSAnimationobject once the animation enters a display:none tree (and there are wpt for this).
Right, of course. Let me clarify what I meant:
Right now we start the animation off styling (that is, when the element gets a new style, or there's a style change). But we stop them based on the presence of frames.
The issue in that test-case is that there's no style change whatsoever, because the "making the contents hidden" bits only happens in the frame constructor, not as a result of a style change. Same thing would happen, I think, with <object> or <embed> fallback.
So there's a disagreement on how those transitions are started and stopped, which is what causes the bug. My proposal was not "let's not stop any animation", but more "let's make the animation-stopping also a result of styling", that is, make them consistent.
But as I look a bit more into it, that becomes a bit more annoying, since pseudo-elements can go away and be recreated. So that doesn't quite work.
|
||
Comment 9•2 years ago
|
||
This is breaking stuff in Firefox View now that we switched to the nice semantic details/summary stuff - see bug 1790083. :-(
Is there some way we can work around, and/or are any of the solutions in comment 3 easy and low-risk enough that you think they could be implemented checks notes this week, before 106 goes into soft freeze? 🙃
|
|
||
Comment 10•2 years ago
|
||
We should just fix bug 1308080. It's not hard but I'm on TPAC this week... Will try to get to it
|
|
||
Comment 11•2 years ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
We should just fix bug 1308080. It's not hard but I'm on TPAC this week... Will try to get to it
Honestly I wonder what other side-effects that would have for the thing we're shipping, and I don't want to add to your workload esp. with TPAC...
If we did something like toggling the hidden attribute on/off on something inside the details tag that contains the animation, is that likely to work around it?
|
|
||
Comment 12•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #11)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
We should just fix bug 1308080. It's not hard but I'm on TPAC this week... Will try to get to it
Honestly I wonder what other side-effects that would have for the thing we're shipping, and I don't want to add to your workload esp. with TPAC...
Not many, in practice, I don't think. It mostly removes code.
If we did something like toggling the
hiddenattribute on/off on something inside thedetailstag that contains the animation, is that likely to work around it?
Possibly? Seems worth a try.
|
|
||
Updated•2 years ago
|
Description
•