Description
Recently, we noticed a Gecko bug about the event order of transitioncancel in Bug 1923208. Per the example this bug, we may have a case when transitioncancel and transitionrun have the same scheduled time.
The example is something like this, when we are replacing a running transition:
<script>
function run() {
target.style.marginLeft = "100px; // We start to run a transition.
setTimeout(() => {
target.style.marginLeft = "200px"; // We replace the running transition
}, 500);
}
</script>
<body onload="run()">
<div id="target" style="transition: margin-left 100s;"></div>
<body>
So basically, in Blink and Webkit, the event order when replacing the transition is:
transitioncancel, transitionrun, .transitionstart
However, in Gecko, the order is:
transitionrun, transitionstart, transitioncancel
These events have the same schedule time, and Gecko puts transitioncancel last.
Per spec, we use the following way to decide the order of them (copied from the comments in the bug):
-
If the scheduled event times are the same then the algorithm is to sort by composite order. That's going to mean we sort as follows:
If A and B’s associated animations differ by class, sort by any inter-class composite order as defined for the corresponding classes. If A and B are still not sorted, sort by any class-specific composite order defined by the common class of A and B’s associated animations. If A and B are still not sorted, sort by the position of their associated animations in the global animation list. -
Since the classes are the same ("transition"), we'll sort by the transition-specific composite order, and then we'll hit step 2 there because the cancelled transitions don't have the owning element:
Otherwise, if only one of A or B has an owning element, let the animation with an owning element sort first.
So it seems we should put the event of the cancelled transition first because it doesn't have the owning element. However, this is not what we expected because we cancel the transition first, and then create the new transition to replace the old one.
We may need to update the spec words to address the case for cancelled transition, e.g. per Brian's suggestion in this Gecko bug:
When sorting cancel events, use the owning element and transition generation from when the transition was cancelled
Also, we have the similar issue for animationcanel (in css-animations-2), and we probably need to figure out how to use animation-name for a cancelled animation.
cc @birtles