Bugzilla

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or something like that), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translate(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case I think.

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps something wrong in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or other places), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translate(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case I think.

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps something wrong in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or other places), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translate(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case I think.

Probably not related to bug 1626165 because the main thread is not busy in this bug, and so this looks like another issue.

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps something wrong in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or other places), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translateX(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case I think.

Probably not related to bug 1626165 because the main thread is not busy in this bug, and so this looks like another issue.

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps something wrong in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or other places), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translateX(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case which should be passed when implementing compositor animations.

Probably not related to bug 1626165 because the main thread is not busy in this bug, and so this looks like another issue.

I suspect we didn't throttle the animation when calling `reset()` (e.g. perhaps something wrong in [PreTraverse](https://searchfox.org/mozilla-central/rev/46d0387f0b582f00a5722c20d4e6b8693793631b/dom/animation/EffectCompositor.cpp#790-796) or other places), so the before-change style is still using `translateX(0px)`, instead of the transform value with the running transition, e.g. `translateX(123px)`. Therefore, we don't create any reversing transition at the moment.

This looks like a regression because this is a basic case which should be passed when implementing compositor animations.

Probably not related to bug 1626165 because the main thread is not busy in this bug, and we didn't even try to create any transitions.