1121667 - Create a preference for time dilation

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Kevin Grandon :kgrandon]

This bug is to implement a preference which speeds up things like CSS animations and setTimeout calls. We would like to be able to set this preference in our automated tests to make them run faster than they currently do.

dev-platform thread: https://groups.google.com/forum/#!msg/mozilla.dev.platform/99FYRz68uLY/Vmo6p0ek-kUJ
related dev-gaia thread: https://groups.google.com/forum/#!searchin/mozilla.dev.gaia/dialation/mozilla.dev.gaia/18dLFLzHF2g/CyfFC6EduUgJ

Comment 1

[Brian Birtles (:birtles)]

I think what we want to do is add document.timeline.playbackRate. I believe the Chrome guys might have added this for their devtools. We could add it as a chrome-only property. We're currently working on supporting playbackRate for individual animations as part of bug 1070744.

Comment 2

[Kevin Grandon :kgrandon]

(In reply to Brian Birtles (:birtles) from comment #1)
> I think what we want to do is add document.timeline.playbackRate. I believe
> the Chrome guys might have added this for their devtools. We could add it as
> a chrome-only property. We're currently working on supporting playbackRate
> for individual animations as part of bug 1070744.

I think we would also want this to impact setTimeout as well. A common use-case is to have a transitionend event listener as well as a fallback setTimeout guard if we don't hit the transitionend. I don't think we would want to change animations without changing setTimeout as well.

Do you think that document.timeline.playbackRate should also impact setTimeout or should we have another flag for setTimeout?

Comment 3

[Brian Birtles (:birtles)]

(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #2)
> I think we would also want this to impact setTimeout as well. A common
> use-case is to have a transitionend event listener as well as a fallback
> setTimeout guard if we don't hit the transitionend. I don't think we would
> want to change animations without changing setTimeout as well.
> 
> Do you think that document.timeline.playbackRate should also impact
> setTimeout or should we have another flag for setTimeout?

document.timeline.playbackRate wouldn't effect setTimeout so we'd need something else for that. I think for tests that actually test the safety timeout we're using the sinon fake timers already though, right?

Ideally we should really drop those safety timeouts altogether. However, in many cases that's going to be difficult without using the Web Animations API, and that API is still preffed off for non-chrome callers in release builds so I'm not sure if that's going to be practical in the short term.

Comment 4

[Kevin Grandon :kgrandon]

(In reply to Brian Birtles (:birtles) from comment #3)
> document.timeline.playbackRate wouldn't effect setTimeout so we'd need
> something else for that. I think for tests that actually test the safety
> timeout we're using the sinon fake timers already though, right?

This would mainly be for our integration tests which don't have sinon, so these currently don't have any concept of fake timers.


> Ideally we should really drop those safety timeouts altogether. However, in
> many cases that's going to be difficult without using the Web Animations
> API, and that API is still preffed off for non-chrome callers in release
> builds so I'm not sure if that's going to be practical in the short term.

I haven't looked into the web animations spec enough to know if we can remove the safety timeouts. I suppose if you have some event that's guaranteed to fire even if dom elements are removed, if the animation is interrupted, or we just miss the frames somehow we could potentially get rid of them.

Comment 5

[Brian Birtles (:birtles)]

(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #4)
> I haven't looked into the web animations spec enough to know if we can
> remove the safety timeouts. I suppose if you have some event that's
> guaranteed to fire even if dom elements are removed, if the animation is
> interrupted, or we just miss the frames somehow we could potentially get rid
> of them.

Yeah, there's a 'finished' promise that provides those guarantees. If the animation has already run when you register, the promise will resolve immediately, and if the transition is cancelled for any reason (interrupted, element removed etc.) the promise will reject. So, you're guaranteed to get a callback.

Comment 6

[Kevin Grandon :kgrandon]

Sounds good and thanks for the info. For now then I think it makes sense to focus on just CSS animation time dilation then. We can always setTimeout dilation in a later bug.

Comment 7

[Andrew Overholt [:overholt]]

Trying for a better component given comment 6.