[web-animations-1] Relative ordering of AnimationPlaybackEvent events

[graouts]

The test timing-model/timelines/update-and-send-events.html has this sub-test:

promise_test(async t => {
  createStyle(t, { '@keyframes anim': '' });
  const div = createDiv(t);

  let receivedEvents = [];
  function receiveEvent(type, timeStamp) {
    receivedEvents.push({ type, timeStamp });
  }

  div.onanimationcancel = event => receiveEvent(event.type, event.timeStamp);
  div.ontransitioncancel = event => receiveEvent(event.type, event.timeStamp);

  getComputedStyle(div).marginLeft;
  div.style = 'animation: anim 100s; ' +
              'transition: margin-left 100s; ' +
              'margin-left: 100px;';
  div.animate(null, 100 * MS_PER_SEC);
  const animations = div.getAnimations();

  animations.forEach(anim => {
    anim.oncancel = event => {
      receiveEvent(animationType(anim) + ':' + event.type, event.timeStamp);
    };
  });

  await Promise.all(animations.map(anim => anim.ready));

  const timeInAnimationReady = document.timeline.currentTime;

  // Call cancel() in reverse composite order.  I.e. canceling for script
  // animation happen first, then for CSS animation and CSS transition.
  // 'cancel' events for these animations should be sorted by composite
  // order.
  animations.reverse().forEach(anim => anim.cancel());

  // requestAnimationFrame callback which is actually the _same_ frame since we
  // are currently operating in the `ready` callbac of the animations which
  // happens as part of the "Update animations and send events" procedure
  // _before_ we run animation frame callbacks.
  await waitForAnimationFrames(1);

  assert_times_equal(timeInAnimationReady, document.timeline.currentTime,
    'A rAF callback should happen in the same frame');

  assert_array_equals(receivedEvents.map(event => event.type),
    // This ordering needs more clarification in the spec, but the intention is
    // that the cancel playback event fires before the equivalent CSS cancel
    // event in each case.
    [ 'CSSTransition:cancel', 'CSSAnimation:cancel', 'ScriptAnimation:cancel',
      'transitioncancel', 'animationcancel' ],
    'cancel events should be sorted by composite order');
}, 'Sorts cancel events by composite order');

This issue is about this comment:

    // This ordering needs more clarification in the spec, but the intention is
    // that the cancel playback event fires before the equivalent CSS cancel
    // event in each case.

I don't see any text in the Web Animations spec or the CSS Transitions and CSS Animations specs that specifies that, if I understand correctly, events of type AnimationPlaybackEvent sort before events of type TransitionEvent or AnimationEvent for otherwise matching conditions.

If that's the intention, we should make that clear.

[birtles]

I don't see any text in the Web Animations spec or the CSS Transitions and CSS Animations specs that specifies that, if I understand correctly, events of type AnimationPlaybackEvent sort before events of type TransitionEvent or AnimationEvent for otherwise matching conditions.

Yeah, in Firefox the playback event is queued first before the CSS animation event. Then because the events have the same scheduled event time and are sorted using a stable sort, they remain in that order.

Per spec, the AnimationPlaybackEvent is queued synchronously as part of the cancel an animation steps with a scheduled event time of timeline time.

The timing of the animationcancel event is not actually specified for the case of a synchronous cancel. It is, however, for an asynchronous one (e.g. via updating style) as per the event dispatch section in CSS animations 2. That section refers to sampling but that definition has been removed so we need to update that. It also doesn't define the scheduled event time but presumably it is also the timeline time when the animation was canceled. So that would still produce the same result of the CSS animation event showing up after the playback event.

So I suppose the following changes are needed:

• Define that the cancel procedure synchronously queues CSS animation/transition events too after the playback events.
• Define the scheduled event time for these events.
• Fix the reference to sampling to whatever the current concept is.