CSS animations execute on display:none elements, so, when display changes later, animation starts in the middle

RESOLVED DUPLICATE of bug 962594

Status

()

defect
RESOLVED DUPLICATE of bug 962594
7 years ago
2 years ago

People

(Reporter: phoenixstyle91, Unassigned)

Tracking

({testcase})

17 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

Considering the following code:

HTML
<div class="class1" style="background-color: #000; width: 100px; height: 100px; position: fixed; top: 0; left: 10; display: none;" id="id1"></div>
<div class="class1" style="background-color: #000; width: 100px; height: 100px; position: fixed; top: 0; left: 40; display: none;" id="id2"></div>

CSS
.class1 {-moz-animation: anim1 25s; -moz-animation-iteration-count- infinite;}
@-moz-keyframes anim1 {0% {top: 0%} 50% {top: 50%} 100% {top: 100%}}

Javascript
var tmr1 = window.setInterval("Display_1()", 1000);
var cCount = 0;
function Display_1() {
if (cCount == 1) {document.getElementById("id1").style.display = "block";} else {document.getElementById("id2").style.display = "block"; clearInterval(tmr1);}
}


Actual results:

The first div appears normally and the animation goes on normally. The second one, once appeared, was exactly in the same position as the first, meaning that the animation declared in the CSS code manages all the div elements in the same way.


Expected results:

In different engines, like Safari or Chrome's one, the elements are managed separately, meaning that the second div element, once appeared, was in position top: 0% and not in the same position as the first. I don't know if this is properly a bug, but a lot of users are having the same problem. We all would really appreciate if there was a CSS attribute to manage these div elements separately by the animation. Thank you.

P.S.: Sorry my English, I'm Italian.
Component: Untriaged → Style System (CSS)
Product: Firefox → Core

Comment 1

7 years ago
Could you attach a minimal testcase (html file), please.
Flags: needinfo?(phoenixstyle91)
Reporter

Comment 2

7 years ago
Posted file testcase (obsolete) —
Flags: needinfo?(phoenixstyle91)

Updated

7 years ago
Attachment #692723 - Attachment mime type: text/plain → text/html
Summary: Animations (CSS) not managed singularly → CSS animations execute on display:none elements, so, when display changes later, animation starts in the middle
Posted file testcase
This version of the testcase is slightly less confusing.  The modifications are:
 * remove prefixes
 * replace the setInterval with a setTimeout since it only runs once
 * remove cCount since it's never modified
 * remove the if (cCount == 1) part since it's never used
 * add <!DOCTYPE HTML>
Attachment #692723 - Attachment is obsolete: true
This shows that we behave differently when an ancestor of the animating element is display:none (as opposed to the animating element itself being display none).
Reporter

Comment 5

7 years ago
Oh, really thank you for the explanation, it works fine! So, the animation which is anyway executed in display:none elements, could be considered as a bug? Could it became "optional", maybe through a CSS property as like "-moz-animation-execute-display-none: (true|false)"?
Blocks: 962594

Comment 6

4 years ago
Per comment 4.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

4 years ago
Did Bug 960465 change anything here?
OS: Windows 7 → All
Hardware: x86_64 → All
The spec now says:

Setting the display property to none will terminate any running animation applied to the element and its descendants. If an element has a display of none, updating display to a value other than none will start all animations applied to the element by the animation-name property, as well as all animations applied to descendants with display other than none.

(and has since http://hg.csswg.org/drafts/rev/f661fd2d5fbe )
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 962594
(It's fixed in Firefox 39.)
You need to log in before you can comment on or make changes to this bug.