Re: [csswg-drafts] [web-animations-1] Ordering of promises and events, and where events are fired (#5582)

> There seems to be some confusion around the ordering of promises and events in the spec.
> 
> https://github.com/web-platform-tests/wpt/blob/master/web-animations/interfaces/Animation/onfinish.html#L30 - the first test assumes the promise callbacks happen before the equivalent event (other tests may too).

Right, I believe that's because in that case we'll run the promise callback microtask before we run the rendering part of the event loop again.

> https://drafts.csswg.org/web-animations-1/#updating-the-finished-state - the promise is 'resolved' before a task is queued to dispatch the event, which could be read as "promise resolves first", but the timing is unclear as no task is queued to perform the resolving.

The resolving happens synchronously, but the callbacks for the promise run as a separate microtask as per the [resolve steps](https://tc39.es/ecma262/#sec-promise-resolve-functions).

> The animation spec probably shouldn't queue tasks to dispatch events at all. Since they're related to rendering, they should be part of [animation events](https://drafts.csswg.org/web-animations/#animation-events), which has a particular step in the [rendering part of the event loop](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model) (11.10). This would also clarify the ordering of CSS animations/transitions vs web animations.

The animation spec only queues tasks to dispatch events when there is no document for timing (e.g. no timeline, or timeline not associated with a document). In all other cases it uses the pending animation event queue that is processed in the rendering part of the event loop.

(As for why it creates a separate task to dispatch events when there is no document for timing, it's because in the past we've had a lot of security bugs arise from running event dispatch synchronously. Since the finish notification steps _can_ be run synchronously, we'd have to be very careful not to assume anything about the state of the world after running them if they also did synchronous event dispatch. In the [update animations and send events procedure](https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events) we ensure the event dispatch is the very last thing to happen for that reason.)

> The event and promise should happen at the 'same time' from the developer's perspective. Since event dispatch is synchronous, and promise callbacks are asynchronous, this means all event listeners should be called before any 'same' promise callbacks. I've asked for some clarification on this in the promises guide [w3ctag/promises-guide#71](https://github.com/w3ctag/promises-guide/issues/71).

To ensure that, I think we'd need to somehow resolve the finished promises in the "update animations and send events" procedure. That sounds a little tricky to me and I wonder if it would be Web-compatible, but if someone wants to try, please do!

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5582#issuecomment-703957274 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 October 2020 00:20:59 UTC