Bug 211986

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:

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	Flags
Reduction	none
simplified test case	none
Further reduction	none

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	Details
simplified test case (2.46 KB, text/html) 2020-05-19 23:15 PDT, Stephen Belovarich	no flags	Details
Further reduction (321 bytes, text/html) 2023-12-13 00:42 PST, Antoine Quint	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Radar WebKit Bug Importer

Comment 1 2020-05-16 16:02:16 PDT

<rdar://problem/63309680>

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

Pull request: https://github.com/WebKit/WebKit/pull/21732

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.