| Summary: | [web-animations] percentage transform values are incorrect if `width` and `height` are animated | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Stephen Belovarich <steveblue> | ||||||||
| Component: | Animations | Assignee: | Antoine Quint <graouts> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Major | CC: | ahmad.saleem792, dino, giffypap79, graouts, graouts, jonlee, simon.fraser, webkit-bug-importer | ||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||
| Version: | Safari 13 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| See Also: |
https://github.com/web-platform-tests/wpt/pull/43647 https://bugs.webkit.org/show_bug.cgi?id=269563 |
||||||||||
| Attachments: |
|
||||||||||
|
Description
Stephen Belovarich
2020-05-16 10:09:44 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. 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. There is also an opacity animation that is wrong during the animation for the nav content. 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? 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. I believe this issue probably has more to do with animating transform with top and right simultaneously. Thanks Stephen, this is great and will help a lot. For future reference, you can attach an HTML file to bugs here. Created attachment 399728 [details]
Reduction
That testcase matches Firefox with a recent WebKit build. Ah, there's a snap at the end. 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. 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.
I observed this is still an issue in Safari Technology Preview 139, which contains a bunch of bug fixes for Web Animations. I am still able to reproduce the jumpy box at the end of animation using "simplified test case" in Safari Technology Preview 160. 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. Yeah, I am able to reproduce in Safari Technology Preview 160 as well. Thanks for reporting Ahmad! 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.
If the animation runs without acceleration (using a `steps()` timing function for instance) then we can clearly see that we have the expected behavior. 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. Retitling the bug to be about the remaining issue since there have been progressions since this bug was originally reported. Pull request: https://github.com/WebKit/WebKit/pull/21732 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/43647 Committed 272022@main (6ab17cf692e2): <https://commits.webkit.org/272022@main> Reviewed commits have been landed. Closing PR #21732 and removing active labels. |