1425014 - During css transition, when class with "transition" property is removed, transition is not cancelled.

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Martin Staffa]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

1) Create a css class that sets the "transition" property, e.g. "transition: all 5s"
2) Create another css class that changes a property that should be animated, e.g. "background: black"
2) Add both classes to an element
3) As the transition is active, remove the class that has the "transition" property

See http://plnkr.co/edit/yP0ImbZ5kiDEPhPLciQ1?p=preview for a runnable example. Hit "Start", then hit "End".


Actual results:

The transition finishes normally.


Expected results:

The transition is aborted, and the final css state is applied immediately.

Chrome 62 and Edge 41 do this.

While it's possible to set "transition: none" to cancel the animation, it's also expected that the transition is cancelled when "transition" is removed implicitly by removing the class that sets it.

Comment 1

[Michał Gołębiowski-Owczarek [:mgol]]

Confirmed. The issue exists in Firefox 57 and it doesn't exist in Chrome 63, Safari 11 & Edge 16. IE 11 stops the animation but leaves it in the intermediate state instead of jumping to the end.

Comment 2

[Akihiko Odaki]

"transition: none" just before removing the property is not enough to workaround this issue. I suspect repaint must be triggered after setting "transition: none" and before the actual removal of the property.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Is this a regression from FF57?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #3)
> Is this a regression from FF57?

It seems not.  The transition does not stop on old style system either.
I will track down what's going on there tomorrow.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Ok, as far as I can tell this behavior matches the spec;

What's going on there is.

There are two classes;

.animate {
  transition: all 5s;
}
.blue {
  .background: black;
}

When |Start| button is pressed, these two classes are appended, so background-color transition starts
When |End| button is pressed, |.animate| class is removed, so the transition-property will be 'initial', it's 'all', and the transition-duration will be 0s.

The spec says [1];
 4. If the element has a running transition for the property, there is a matching transition-property value, and the end value of the running transition is *not* equal to the value of the property in the after-change style, then:

So at this moment the end value of the transition background-color is 'black' and the after-change's one is also 'black'.  So we don't cancel the transition.  If the spec did not say this condition, the transition will be cancelled since we will meet the below condition.

  2. Otherwise, if the combined duration is less than or equal to 0s, or if the current value of the property in the running transition cannot be interpolated with the value of the property in the after-change style, then implementations must cancel the running transition.

Brian, is this correct?

[1] https://drafts.csswg.org/css-transitions/#starting

Comment 6

[Brian Birtles (:birtles)]

Yes, your reading of the spec is correct and this is the intended behavior. We shouldn't change the duration of running transitions. To cancel the transition, one should change the transition-property property accordingly (to 'none' etc.) and then it will be removed on the next restyle.

This appears to be a Chrome/Edge bug. If I finally get the wpt transitions test suite into a good shape we could add a test for this.