Bug 161535

Summary: Implement the transitioncancel event
Product: WebKit Reporter: Chris Rebert <webkit>
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Severity: Normal CC: dino, jonlee, simon.fraser
Priority: P2 Keywords: W3CTest
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
URL: https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1264125

Description Chris Rebert 2016-09-02 09:51:04 PDT
Specification: https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel

Steps to reproduce the problem:
1. Open the CSSWG testcase https://github.com/w3c/csswg-test/blob/master/css-transitions-2/transitioncancel-001.html in Safari.

What is the expected behavior?
The test should pass.

What went wrong?
The test failed, indicating that Safari is not firing the transitioncancel event when a transition is canceled.
(In this case, the cancellation is due to the element being made display:none; while the transition was in progress.)

Without transitioncancel, scripts which are waiting for the end (whether normal or canceled early) of a CSS transition have to resort
to using setTimeout (or similar) to ensure that their callbacks still get called even if the transition gets canceled.
This extra complexity is annoying to authors, and frameworks often include such setTimeout-based workarounds in practice, for example:
* https://github.com/twbs/bootstrap/blob/c56219d223af5145c171defb9fa1426e1dd022f3/js/transition.js#L36
* https://github.com/Semantic-Org/Semantic-UI/blob/f725b162e70896e38257965424ac7f9af486b927/src/definitions/modules/transition.js#L441
Such extra setTimeout()s also presumably have a negative impact on performance.
Comment 1 Jon Lee 2019-06-19 17:17:00 PDT

*** This bug has been marked as a duplicate of bug 183864 ***