[web-animations-1] Finished pending state

[verbessern]

The pending play/pause micro tasks are canceled when the right conditions exist, but the finished micro task is not. Its let to itself to just do nothing when its executed in 4.4.12. Updating the finished state: finish notification steps, step 1.. Is there some specific reason for this? Is it planned to cancel the finished pending micro task in the same way as the play/pause tasks in the future?

[birtles]

I'm afraid I don't understand the question. The play/pause procedures queue a task in some cases. That queued task may be canceled under certain circumstances. The steps to update an animation's finished task are not queued but are run synchronously.

[verbessern]

4.4.12. Updating the finished state: finish notification steps, step 2: "Otherwise, if synchronously notify is false, queue a microtask to run finish notification steps for animation unless there is already a microtask queued to run those steps for animation." Here a finished microtask can be queued, but nowhere this task is canceled if the animation, before the task is run, becomes not finished, and for this case is the "4.4.12./5.1.1 If animation’s play state is not equal to finished, abort these steps.". I.e. the microtask stays in the micro tasks queue always, until is executed.

[verbessern]

Let me guide you: "class AsyncFinishNotification : public MicroTaskRunnable" in Animations.cpp of the code you have referenced to me in another issue. This is the pending finished notification micro task. In this code it seems that this queue is not the same as the "PendingAnimationTracker", so maybe that will produce out of order execution of pause/play/finish notify tasks (because that are two different queues), but I'm not sure, its not the topic of the issue however.

[birtles]

Oh, I see, this is about dispatching the finish event. Do you have a specific case in mind that is of concern?

Those steps begin with a check that the play state is still finished, so the microtask effectively cancels itself if the conditions for running it are no longer met.

[verbessern]

I would like to have a case, but its too complicated. It will also be hard to produce a case, because to test it, you will use this code, that has this 2 queues, that is not as its the specification (that has only one micro task queue). So i have to first understand this source code, to produce a bug report for it, that I'm not willing to do it. I have just seen that this finished notification micro task is different from the other 2 micro tasks, and so filed the issue, because its suspicious.

[birtles]

Right, the PendingAnimationTracker is used to run the steps corresponding to the task (not microtask) for when an animation becomes ready. The AsyncFinishNotification is used to run the microtask for finish notifications. I believe this is to spec since the spec is deliberately vague about what "ready" means (so that implementations can choose the optimal timing in order to produce smooth animation) and hence when those steps actually run. It doesn't require they are scheduled as a microtask and so it is expected there are two queues.

[verbessern]

Its hard for me to understand the above, but maybe after I read more I will re-read it. However, about task/microtask difference I disagree, see that "4.4.8. Playing an animation: 11 end: If a user agent determines that animation is immediately ready, it may schedule the above task as a microtask such that it runs at the next microtask checkpoint, but it must not perform the task synchronously." Also in "4.4.9. Pausing an animation: 10 end: As with the pending play task, the user agent must run the pending pause task asynchronously, although that may be as soon as the next microtask checkpoint."

[verbessern]

Ah yes, ok, for the 4.4.9 you are right, but what about 4.4.8?

[birtles]

Those are saying the same thing, the timing for the ready steps is up to the user agent, but the requirement is that it must not be run synchronously. The earliest possible opportunity is to schedule it as a microtask, but it is not required to be scheduled as such, hence having two queues (or more accurately two sources for scheduling these steps) is per spec.

[verbessern]

I understand now, the play/pause could be microtasks, but may not be, and the finished notification is always a microtask. Its very hard to understand by only reading the specification. I would vote for some prose text in the specification about this task/microtask. Thank you for the clarification.

[verbessern]

Btw, this does not address the issue in question, but by understanding more now, I can't actually question the validity of the "not canceling the finished notification microtask", because its related to queues that I don't know how they operate, so I have closed the question.

[verbessern]

OK, my suspicious is growing. When the pending finished notification micro task is run, as an element of the micro task queue, where the promises are also queued (as far as I'm reading around), that means that the resolving the finished promise (finish notification steps, step 2), may trigger a sequence of changes (play/set current time, run in the same micro task cycle) to the animation, that cause the finish notification micro task, again, asynchronously, to be added to the micro task queue.
This may cause a stall of the micro task queue, because its run till depletion. That effect can't be observed in the play/pause simple tasks, because they are not using the micro task queue (at least in the implementation in question), even that they are also resolving a promise (the ready one). If what I'm deducting is true, then if the finished notification is also run out of the micro task queue as the play/pause tasks, then that could be prevented.