RESOLVED FIXED 211986
[web-animations] percentage transform values are incorrect if `width` and `height` are animated
https://bugs.webkit.org/show_bug.cgi?id=211986
Summary [web-animations] percentage transform values are incorrect if `width` and `he...
Stephen Belovarich
Reported 2020-05-16 10:09:44 PDT
When using this animation on https://stephenbelovarich.com, the transition appears correct for all browsers except Safari (MacOS and iOS). When animating the element with Web Animations API, the transition starts, then at the end appears stuck, snapping into place. It appears easing is not being applied correctly. Reproducible with any easing and fill. ``` { keyframes: [ { transform: 'translateX(0%) translateY(0%)', width: '44px', top: '0%', right: '0%' }, { transform: 'translateX(50%) translateY(-50%)', width: '320px', top: '50%', right: '50%' } ], options: { fill: 'forwards', easing: 'ease-in-out', duration: 700 } } ``` The element has this CSS: ``` nav { position: absolute; display: block; top: 0%; right: 0%; width: 44px; height: 44px; transform: translateX(0%) translateY(0%); text-align: center; ``` Steps to reproduce: Visit https://stephenbelovarich.com Click on hamburger menu Observe transition is incorrect in Safari, correct in Chrome and Firefox. I'm not sure if this is a duplicate of 210526. The issue seemed like it could be different.
Attachments
Reduction (556 bytes, text/html)
2020-05-19 03:58 PDT, Antoine Quint
no flags
simplified test case (2.46 KB, text/html)
2020-05-19 23:15 PDT, Stephen Belovarich
no flags
Further reduction (321 bytes, text/html)
2023-12-13 00:42 PST, Antoine Quint
no flags
Radar WebKit Bug Importer
Comment 1 2020-05-16 16:02:16 PDT
Antoine Quint
Comment 2 2020-05-18 02:28:46 PDT
Seems to be a transform-origin issue, the text content grows as if the origin is the top-right corner instead of its center like it does in Firefox.
Antoine Quint
Comment 3 2020-05-18 02:44:08 PDT
I don't think this is related to easing at all, it's a transform problem as far as I can tell. Retitling to reflect this. This is also not a regression in the new Web Animations engine.
Antoine Quint
Comment 4 2020-05-18 02:53:31 PDT
There is also an opacity animation that is wrong during the animation for the nav content.
Antoine Quint
Comment 5 2020-05-18 02:54:45 PDT
Stephen, it would help if you could provide somewhat reduced content for this example. Could you make a simpler test that is just the menu animation, removing any additional content, and possibly not using shadow roots or anything more than just the necessary HTML, CSS and JS?
Stephen Belovarich
Comment 6 2020-05-18 17:03:51 PDT
Here you go. I have nowhere to host trimmed down example except Codepen. I removed the CSS animation keyframes so you can focus on just the Web Animations API animation. https://codepen.io/steveblue/pen/zYvMLpp The opacity issue you described has been fixed since you reviewed on stephenbelovarich.com, good catch, I found that too! I tried adding `transform-origin: 50% 50%` but that didn't help. To be clear, I am animating the top and right while also animating the transform which should provide a centered effect without transform-origin.
Stephen Belovarich
Comment 7 2020-05-18 17:14:20 PDT
I believe this issue probably has more to do with animating transform with top and right simultaneously.
Antoine Quint
Comment 8 2020-05-19 02:56:38 PDT
Thanks Stephen, this is great and will help a lot. For future reference, you can attach an HTML file to bugs here.
Antoine Quint
Comment 9 2020-05-19 03:58:39 PDT
Created attachment 399728 [details] Reduction
Simon Fraser (smfr)
Comment 10 2020-05-19 11:15:33 PDT
That testcase matches Firefox with a recent WebKit build.
Simon Fraser (smfr)
Comment 11 2020-05-19 12:17:11 PDT
Ah, there's a snap at the end.
Stephen Belovarich
Comment 12 2020-05-19 13:56:46 PDT
Yes, the issue is most prominent at the end of the animation in, clicking on the button reveals the second animation also makes the element go off screen in Safari and not in Chrome and Firefox.
Stephen Belovarich
Comment 13 2020-05-19 23:15:30 PDT
Created attachment 399816 [details] simplified test case This is a simplified reproduction of the issue. index.html includes styling, Web Animations API example, and html.
Stephen Belovarich
Comment 14 2022-02-05 13:18:10 PST
I observed this is still an issue in Safari Technology Preview 139, which contains a bunch of bug fixes for Web Animations.
Ahmad Saleem
Comment 15 2022-12-14 16:50:27 PST
I am still able to reproduce the jumpy box at the end of animation using "simplified test case" in Safari Technology Preview 160.
Stephen Belovarich
Comment 16 2022-12-14 17:04:52 PST
Ahmad, I just opened the simplified test case and still observe the issue in Safari Technology Preview 160. Observe the square translates smoothly, then snaps at the end in place. This "snap" is not intended. Observe the same transition in another browser like Chrome or Firefox, the translation is smooth on the x and y axis, there is no snap, unlike in Safari Technology Preview. The issue is perhaps more pronounced here https://stephenbelovarich.com. Click the menu in the top right to observe the same issue. The menu with the two lines smoothly transitions in other browsers, while the menu translates too far to the left in Safari Technology Preview 160 and then snaps into place, which is not as intended.
Stephen Belovarich
Comment 17 2022-12-14 17:08:22 PST
Yeah, I am able to reproduce in Safari Technology Preview 160 as well. Thanks for reporting Ahmad!
Antoine Quint
Comment 18 2023-12-13 00:42:15 PST
Created attachment 469013 [details] Further reduction I don't know if this covers all of the issues in the original report, but I have a further-reduced sample which indicates that we resolve `transform` values independently of the animated `width` and `height` values: div { width: 10px; height: 10px; background-color: black; animation: anim 1s linear forwards; } @keyframes anim { to { width: 200px; height: 200px; transform: translate(50%, 50%); } } We snap at the end when we resolve `translate(50%, 50%)` to account for the new `width` and `height` values.
Antoine Quint
Comment 19 2023-12-13 00:44:05 PST
If the animation runs without acceleration (using a `steps()` timing function for instance) then we can clearly see that we have the expected behavior.
Antoine Quint
Comment 20 2023-12-13 00:45:14 PST
I think we may have to opt out of acceleration in this case. We don't actually gain much anyway since we'll have perform a new layout on each frame due to the `width` and `height` changes.
Antoine Quint
Comment 21 2023-12-13 00:46:48 PST
Retitling the bug to be about the remaining issue since there have been progressions since this bug was originally reported.
Antoine Quint
Comment 22 2023-12-13 07:37:13 PST
Antoine Quint
Comment 23 2023-12-13 07:47:47 PST
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/43647
EWS
Comment 24 2023-12-14 00:58:58 PST
Committed 272022@main (6ab17cf692e2): <https://commits.webkit.org/272022@main> Reviewed commits have been landed. Closing PR #21732 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.