161535 2016-09-02 09:51:04 -0700 Implement the transitioncancel event 2019-06-19 17:17:00 -0700 1 1 1 Unclassified WebKit Animations WebKit Nightly Build All All RESOLVED DUPLICATE 183864 https://bugzilla.mozilla.org/show_bug.cgi?id=1264125 https://bugs.chromium.org/p/chromium/issues/detail?id=642487 https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitioncancel W3CTest P2 Normal --- 1 webkit webkit-unassigned dino jonlee simon.fraser oldest_to_newest 1225796 0 webkit 2016-09-02 09:51:04 -0700 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. 1546311 1 jonlee 2019-06-19 17:17:00 -0700 *** This bug has been marked as a duplicate of bug 183864 ***