23775 2009-02-05 16:39:09 -0800 Transitions misbehave when a property is expressed in different units 2026-02-09 06:47:07 -0800 1 1 1 Unclassified WebKit Animations 528+ (Nightly build) Mac OS X 10.5 RESOLVED CONFIGURATION CHANGED https://bugs.webkit.org/show_bug.cgi?id=245179 BrowserCompat, HasReduction, InRadar P2 Normal --- 1 marchant webkit-unassigned ahmad.saleem792 ap bdakin bfulgham cedricv dino divya graouts rik simon.fraser webkit-bug-importer webkit.org zalan oldest_to_newest 108552 0 marchant 2009-02-05 16:39:09 -0800 In the attached test case, the width doesn't animate because it's expressed as % at the beginning and as em when the transition should apply 108553 1 27370 marchant 2009-02-05 16:40:18 -0800 Created attachment 27370 Test case for the bug 108556 2 desamo 2009-02-05 17:39:59 -0800 rdar://problem/6561547 416280 3 simon.fraser 2011-06-06 21:09:49 -0700 *** Bug 54647 has been marked as a duplicate of this bug. *** 507909 4 mikelawther 2011-11-22 19:25:19 -0800 *** Bug 63309 has been marked as a duplicate of this bug. *** 1895643 5 ahmad.saleem792 2022-09-01 16:34:48 -0700 I am not able to reproduce issue in reference to animation but the animation ends abruptly if mouse leaves container and come back in Safari Technology Preview 152 and it is not same as other browsers, where the animation ends back smoothly. Do you want me to create separate bug for that and close this? Appreciate if someone can comment. Thanks! 1895940 6 ap 2022-09-02 17:46:41 -0700 Good catch. This problem with interrupted transition only reproduces when the units are different, so I would say that it's a part of the original bug, and can continue to be tracked here. Re-titled a bit to that effect. 1898443 7 462331 graouts 2022-09-14 05:30:27 -0700 Created attachment 462331 Improved testcase In the attached improved testcase, we automatically trigger, reverse the transition and log the values provided by the Web Animations API which are all out of whack in WebKit. 1898444 8 graouts 2022-09-14 05:35:28 -0700 Firefox / Chrome (actual values may vary): Transitioning width from 10% to 960px Transitioning width from calc(6.63989% + 322.571px) to 10% Safari: Transitioning width from 151.1875px to 151.1875px Transitioning width from 151.1875px to 151.1875px What puzzles me is that the from/to values are the same for the initial transition even though we do the right thing in terms of rendering. The second one is consistent with the fact that we snap, although it makes no sense to transition between two equal values. 1898445 9 graouts 2022-09-14 05:40:59 -0700 We are getting 10% and 960px values in the RenderStyle objects provided when creating the CSSTransition object. 1898454 10 graouts 2022-09-14 06:33:43 -0700 Huh-ho, so for the getKeyframes() issue the problem is that we are calling this method to get the computed value from the style in the addPropertyToKeyframe lambda: computedStyleExtractor.valueForPropertyInStyle(style, cssPropertyId, renderer) But this absolutely does not use the provided style object to get the width instead using the current bounds for the renderer. Not good! 1898462 11 graouts 2022-09-14 07:51:10 -0700 Filed bug 245179 for the getKeyframes() issue which is unrelated to the fact that we're not visibly animating for transition reversal. 1899497 12 graouts 2022-09-19 09:03:54 -0700 The issue is under static Length blendMixedTypes(const Length& from, const Length& to, const BlendingContext& context) where we have from = calc(blend(10%, 960px, 0.33)) and to = 10% but the result is calc(blend(10%, 10%, …)). 1899500 13 graouts 2022-09-19 09:05:24 -0700 I think this might be the culprit: CalcExpressionBlendLength::CalcExpressionBlendLength(Length from, Length to, float progress) : CalcExpressionNode(CalcExpressionNodeType::BlendLength) , m_from(from) , m_to(to) , m_progress(progress) { // Flatten nesting of CalcExpressionBlendLength as a speculative fix for rdar://problem/30533005. // CalcExpressionBlendLength is only used as a result of animation and they don't nest in normal cases. if (m_from.isCalculated() && m_from.calculationValue().expression().type() == CalcExpressionNodeType::BlendLength) m_from = downcast<CalcExpressionBlendLength>(m_from.calculationValue().expression()).from(); if (m_to.isCalculated() && m_to.calculationValue().expression().type() == CalcExpressionNodeType::BlendLength) m_to = downcast<CalcExpressionBlendLength>(m_to.calculationValue().expression()).to(); } 1899501 14 graouts 2022-09-19 09:07:42 -0700 Indeed, removing that code fixes the issue. But this fixed a crash so we probably need to find a better way to flatten blend calculation values here. 2178715 15 ahmad.saleem792 2026-02-06 02:01:04 -0800 @Antoine - I am unable to reproduce this bug on Safari Technology Preview 236 and neither could I find comment about rdar://problem/30533005 anymore? Could be fixed by Sam's rewrite of calc()? 2179435 16 graouts 2026-02-09 06:46:56 -0800 I think this is the case. I simply can't go far enough in history to find a failing Safari to then find when this progressed. 27370 2009-02-05 16:40:18 -0800 2009-02-05 16:40:18 -0800 Test case for the bug BugWidth.html text/html 884 marchant PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIKCSJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4KCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6 bGFuZz0iZW4iIGxhbmc9ImVuIj4KPGhlYWQ+Cgk8dGl0bGU+Q1NTQW5pbWF0aW9uVGVzdDwvdGl0 bGU+CgoJPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KCQkKCQkuc3RhcnR7CiAgICAgICAgICAgIC13 ZWJraXQtdHJhbnNpdGlvbi1kdXJhdGlvbjogM3M7CiAgICAgICAgICAgIC13ZWJraXQtdHJhbnNp dGlvbi1wcm9wZXJ0eTogd2lkdGg7CiAgICAgICAgICAgIC13ZWJraXQtdHJhbnNpdGlvbi10aW1p bmctZnVuY3Rpb246IGVhc2U7CgkJCWJhY2tncm91bmQtY29sb3I6IGJsdWU7CgkJCWNvbG9yOiBi bGFjazsKCQkJZm9udC1zaXplIDogMjBweDsKCQkJaGVpZ2h0IDogNzBweDsKCQkJd2lkdGggOiA0 MCU7CgkJCXBvc2l0aW9uOmFic29sdXRlOwoJCQlwYWRkaW5nOjEwcHg7CgkJCXRvcCA6IDEwMHB4 OwoJCQlsZWZ0IDogMTEwcHg7CgkJCWJvcmRlcjogMnB4IHNvbGlkIGRhcmttYWdlbnRhOwoJCX0K CQkKCQkjY2xpY01lOmhvdmVyIHsKCQkJd2lkdGggOiA2MGVtOwoJCX0KCQkKCTwvc3R5bGU+ICAK PC9oZWFkPgoKPGJvZHkgaWQ9IkdpYW5kdWlhLnRlc3QuQXBwS2l0LnRlc3ROU0NvbXBvbmVudCI+ Cgk8aDE+RXhhbXBsZSBvZiB1c2FnZSBvZiBOU0NTU0FuaW1hdGlvbjwvaDE+Cgk8ZGl2IGlkPSJj bGljTWUiIGNsYXNzPSJzdGFydCIgIG9uY2xpY2s9InRlc3RBbmltYXRpb25zKCk7IiA+CgkJQ2xp YyBNZQoJPC9kaXY+CjwvYm9keT4KPC9odG1sPgo= 462331 2022-09-14 05:30:27 -0700 2022-09-14 05:30:27 -0700 Improved testcase bug-23775.html text/html 774 graouts PGh0bWw+CjxoZWFkPgoJPHRpdGxlPlRlc3QgZm9yIGJ1ZyAyMzc3NTwvdGl0bGU+Cgk8c3R5bGU+ CgkJCmRpdiB7Cglwb3NpdGlvbjogYWJzb2x1dGU7Cgl0b3A6IDEwMHB4OwoJbGVmdDogMTAwcHg7 Cgl3aWR0aDogMTAlOwoJaGVpZ2h0OiA3MHB4OwoKCWJhY2tncm91bmQtY29sb3I6IGJsYWNrOwog ICAgdHJhbnNpdGlvbjogd2lkdGggM3MgbGluZWFyOwp9CgpkaXYucmV0YXJnZXRlZCB7Cgl3aWR0 aCA6IDYwZW07Cn0KCgk8L3N0eWxlPiAgCjwvaGVhZD4KCjxib2R5Pgo8ZGl2PjwvZGl2Pgo8c2Ny aXB0PgoKY29uc3QgdGFyZ2V0ID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcigiZGl2Iik7Cgp0YXJn ZXQuYWRkRXZlbnRMaXN0ZW5lcigidHJhbnNpdGlvbnN0YXJ0IiwgZXZlbnQgPT4gewogICAgY29u c3QgcHJvcGVydHkgPSBldmVudC5wcm9wZXJ0eU5hbWU7CiAgICBjb25zdCBrZXlmcmFtZXMgPSB0 YXJnZXQuZ2V0QW5pbWF0aW9ucygpWzBdLmVmZmVjdC5nZXRLZXlmcmFtZXMoKTsKICAgIGNvbnNv bGUubG9nKGBUcmFuc2l0aW9uaW5nICR7cHJvcGVydHl9IGZyb20gJHtrZXlmcmFtZXNbMF1bcHJv cGVydHldfSB0byAke2tleWZyYW1lc1sxXVtwcm9wZXJ0eV19YCk7Cn0pOwoKY29uc3QgdG9nZ2xl ID0gKCkgPT4gdGFyZ2V0LmNsYXNzTGlzdC50b2dnbGUoInJldGFyZ2V0ZWQiKTsKCnNldFRpbWVv dXQoKCkgPT4gewogICAgdG9nZ2xlKCk7CiAgICBzZXRUaW1lb3V0KHRvZ2dsZSwgMTAwMCk7Cn0p OwogICAgCjwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K