Open
Bug 1509746
Opened 7 years ago
Updated 5 months ago
Ensure animationiteration event is fired
Categories
(Core :: CSS Transitions and Animations, enhancement, P3)
Core
CSS Transitions and Animations
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox65 | --- | affected |
People
(Reporter: hiro, Unassigned)
References
Details
Attachments
(1 file)
835 bytes,
text/html
|
Details |
If the main-thread is busy in the initial frame where the animation is painted and if the busyness persists until animation iteration change happens we don't fire animationiteration event.
On Chrome the event is fired.
Comment 1•7 years ago
|
||
I believe that's per spec. Iteration events are only fired when we have main thread animation frames within the active interval. There's no guarantee that any will be fired. Chrome also drops them in many cases.
Reporter | ||
Comment 2•7 years ago
|
||
From web developers perspective it's not intuitive because the animation iteration change actually can be visible on the content.
Comment 3•7 years ago
|
||
I'm not sure exactly what you're proposing. I don't think we want to solve this in the general case since you can have an animation with a 1ms interval (or much less) and we don't expect UAs to dispatch all the animationiteration events. All the spec requires is that you get the latest one for the current frame.
Component: DOM: Animation → CSS Transitions and Animations
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•