Closed
Bug 822092
Opened 12 years ago
Closed 10 years ago
CSS animations execute on display:none elements, so, when display changes later, animation starts in the middle
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 962594
People
(Reporter: phoenixstyle91, Unassigned)
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
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.
Updated•12 years ago
|
Component: Untriaged → Style System (CSS)
Product: Firefox → Core
Could you attach a minimal testcase (html file), please.
Flags: needinfo?(phoenixstyle91)
Attachment #692723 -
Attachment mime type: text/plain → text/html
Updated•12 years ago
|
Summary: Animations (CSS) not managed singularly → CSS animations execute on display:none elements, so, when display changes later, animation starts in the middle
Comment 3•12 years ago
|
||
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
Comment 4•12 years ago
|
||
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).
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)"?
Comment 7•10 years ago
|
||
Did Bug 960465 change anything here?
OS: Windows 7 → All
Hardware: x86_64 → All
Comment 8•10 years ago
|
||
No.
Comment 10•10 years ago
|
||
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 )
Comment 11•10 years ago
|
||
Though bug 962594 should have fixed this.
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Comment 13•10 years ago
|
||
(It's fixed in Firefox 39.)
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•