Re: [web-animations] Updating the finish promise in a separate task

If I understand this correctly, there are really two questions here:

1) Whether certain operations on animation objects should have synchronous
or asynchronous semantics;
2) Whether executing two asynchronous operations that cancel each other out
should behave as if neither ever happened

I think 2) is not necessarily a foregone conclusion.  The alternative would
be to behave as if both really did happen, in the order specified.  I don't
know whether this is complicated to implement, or even desirable, but I
wanted to bring it up for consideration.

- Kris


On Mon, Jun 29, 2015 at 10:58 PM, Brian Birtles <bbirtles@mozilla.com>
wrote:

> On 2015/06/30 13:21, Brian Birtles wrote:
>
>> Hi,
>>
>> I'm currently speccing finish/cancel events for animations and I think
>> it makes sense to dispatch finish events and also update the finished
>> promise in a separate task.
>>
>
> I was thinking of applying similar handling to the cancel event including
> the part where we cancel a pending finished promise.
>
> However, a consequence of this handling is it means that in the following
> case:
>
>   anim.finish();
>   anim.currentTime = 0;
>
> the finished promise won't resolve. Nor will any finish event fire.
>
> Likewise, if you say:
>
>   anim.finish();
>   anim.cancel();
>   anim.currentTime = 0;
>
> The finished promise won't fulfill or reject. Nor will the finish or
> cancel event fire.
>
> Is that weird?
>
> I wonder if we the following behavior is more intuitive:
>
> 1. cancel() queues event dispatch / promise rejection synchronously
>    such that calling cancel() always triggers a cancel event unless
>    the animation is already idle.
>
> 2. finish() likewise queues event dispatch / promise resolution
>    synchronously unlike simply setting the currentTime.
>
> (3. A timeline going inactive should cause us to update the hold time
>     of any animation watching it. This is consistent with what happens
>     when we set animation.timeline = null and means the only time we
>     ever transition to the idle state is from a call to cancel().)
>
> Best regards,
>
> Brian
>
>