Bug 201048

Summary: Accelerated animations freeze on render tree rebuild
Product: WebKit Reporter: Liam DeBeasi <ldebeasi>
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, dino, emilio, esprehn+autocc, ews-watchlist, glenn, graouts, koivisto, kondapallykalyan, niklasmerz, pdr, rniwa, simon.fraser, timdream, webkit-bug-importer, webkit, zalan
Priority: P2 Keywords: InRadar
Version: Safari 12   
Hardware: All   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=204805
https://bugs.webkit.org/show_bug.cgi?id=207359
Bug Depends on:    
Bug Blocks: 148695    
Attachments:
Description Flags
Sample app shown on iOS 12
none
Sample app on iOS 13
none
patch
graouts: review+
patch
none
patch none

Liam DeBeasi
Reported 2019-08-22 12:47:00 PDT
When animating an element within a shadow root in a custom element, layout invalidations via `Node.insertBefore` cause the animation to freeze. This does not happen when using a custom element without a shadow root. I am able to reproduce this in Safari 12 on both iOS and macOS. Code reproduction: https://codepen.io/liamdebeasi/pen/YzKNGzW Steps to reproduce: 1. Go to the link above. 2. You should see a box that is rotating, as well as a button. 3. Click the "Click Me" button. 4. Notice that the box stops rotating. 5. Subsequent clicks of the "Click Me" button will cause the animation to render for a frame and then stop again. Hovering over the ".square" element in Web Inspector will reveal that the animation is still playing. The "highlight" that appears over the element in the DOM tree should update every time you hover over it. Switching to another tab and then back to the original tab somehow fixes the issue. This bug does not happen when using a custom element without a shadow root, as seen in this code example: https://codepen.io/liamdebeasi/pen/xxKgErw (follow the same steps as before) As an additional reference, Angular can sometimes call `Node.insertBefore` when running change detection. This can cause animations in a user's application to break when using the shadow DOM. See https://github.com/ionic-team/ionic/issues/17202 for more info) Web Animations API Note: The same bug affects Safari's implementation of the Web Animations API (tested using Safari Technology Preview 90). With just "Web Animations" enabled in "Experiments", the tab switching trick mentioned above does not work. When also enabling "CSS Animations via Web Animations" the tab switching trick works. Web Animations Code Reproduction: https://codepen.io/liamdebeasi/pen/LYPxbed
Attachments
Sample app shown on iOS 12 (180.98 KB, video/quicktime)
2019-12-19 01:22 PST, Niklas Merz
no flags
Sample app on iOS 13 (2.50 MB, video/quicktime)
2019-12-19 01:32 PST, Niklas Merz
no flags
patch (9.23 KB, patch)
2020-02-03 08:25 PST, Antti Koivisto
graouts: review+
patch (9.45 KB, patch)
2020-02-03 09:12 PST, Antti Koivisto
no flags
patch (9.46 KB, patch)
2020-02-03 09:34 PST, Antti Koivisto
no flags
Radar WebKit Bug Importer
Comment 1 2019-08-22 13:47:37 PDT
Niklas Merz
Comment 2 2019-11-15 06:32:12 PST
I can add that this seems to be a regression. The same transitions work more smoothly on iOS 12.4 than on iOS 13.
Niklas Merz
Comment 3 2019-12-19 01:22:32 PST
Created attachment 386084 [details] Sample app shown on iOS 12
Niklas Merz
Comment 4 2019-12-19 01:32:03 PST
Created attachment 386085 [details] Sample app on iOS 13 I just built a small sample with Ionic that shows why this bug is really bad for the UX. The same app runs on iOS 12 better and the animation is less stuttering. That's why I think this might be a regression.
Niklas Merz
Comment 5 2020-01-27 01:58:37 PST
Sorry for the ping. This is really a huge UX flaw for page transitions in Ionic apps with certain pages. Can we do anything to get this fixed? Thanks
Ryosuke Niwa
Comment 6 2020-01-28 23:23:06 PST
(In reply to Niklas Merz from comment #5) > Sorry for the ping. This is really a huge UX flaw for page transitions in > Ionic apps with certain pages. I appreciate that you provided this detail. It allows us to priorities this bug better. > Can we do anything to get this fixed? It would be ideal if we had a minimum reproduction that doesn't rely on custom elements instead of https://codepen.io/liamdebeasi/pen/YzKNGzW but it's not a big deal. I can easily make a reduction myself. FWIW, I don't think I can work on it anytime soon due to other commitments. Having said that, it's probably not that hard to diagnose this issue even as the first WebKit bug for someone so if you can find someone who can work on this that might work too.
Liam DeBeasi
Comment 7 2020-01-29 06:06:53 PST
(In reply to Ryosuke Niwa from comment #6) > It would be ideal if we had a minimum reproduction that doesn't rely on > custom elements instead of https://codepen.io/liamdebeasi/pen/YzKNGzW but > it's not a big deal. I can easily make a reduction myself. > > FWIW, I don't think I can work on it anytime soon due to other commitments. > Having said that, it's probably not that hard to diagnose this issue even as > the first WebKit bug for someone so if you can find someone who can work on > this that might work too. I can try and diagnose it a bit, though I am not very familiar with the WebKit code base. What kind of reproduction would be helpful here? The issue only happens with custom elements/Shadow DOM, so I am not sure that a reproduction without custom elements is possible here.
Tim Guan-tin Chien [:timdream]
Comment 8 2020-02-02 19:22:38 PST
Maybe the test case in bug 204805 can be helpful.
Antti Koivisto
Comment 9 2020-02-03 06:55:06 PST
*** Bug 204805 has been marked as a duplicate of this bug. ***
Antti Koivisto
Comment 10 2020-02-03 06:55:56 PST
204805 has working WIP patch and test case without shadow trees.
Antti Koivisto
Comment 11 2020-02-03 08:25:01 PST
Antoine Quint
Comment 12 2020-02-03 08:30:34 PST
Comment on attachment 389514 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=389514&action=review > LayoutTests/webanimations/accelerated-animation-renderer-change.html:48 > + await new Promise(resolve => setTimeout(resolve, 50)); It would be preferable to get a reference to the animation using element.getAnimations() and then wait for its ready promise to resolve and then wait one frame using requestAnimationFrame(), that way there is no setTimeout() involved. > LayoutTests/webanimations/accelerated-animation-renderer-change.html:54 > + await new Promise(resolve => setTimeout(resolve, 500)); Ideally we could use requestAnimationFrame here too, possibly with 2 frames to guarantee the animation would have ticked a couple of times.
Antti Koivisto
Comment 13 2020-02-03 09:12:50 PST
Antti Koivisto
Comment 14 2020-02-03 09:34:29 PST
WebKit Commit Bot
Comment 15 2020-02-03 21:56:09 PST
Comment on attachment 389527 [details] patch Clearing flags on attachment: 389527 Committed r255663: <https://trac.webkit.org/changeset/255663>
WebKit Commit Bot
Comment 16 2020-02-03 21:56:11 PST
All reviewed patches have been landed. Closing bug.
Antti Koivisto
Comment 17 2020-02-06 15:00:52 PST
Niklas Merz
Comment 18 2020-02-20 23:16:44 PST
I just did a quick test with Safari Technology Preview on macOS and the latest iOS 13.4 Developer Beta 2. Looks like the issue is fixed and the patch has landed in the beta versions! The codepen works now and the page transitions in our app are much smoother! Thank you very much for fixing this.
Ryosuke Niwa
Comment 19 2020-02-21 00:05:13 PST
(In reply to Niklas Merz from comment #18) > I just did a quick test with Safari Technology Preview on macOS and the > latest iOS 13.4 Developer Beta 2. Looks like the issue is fixed and the > patch has landed in the beta versions! > > The codepen works now and the page transitions in our app are much smoother! Thanks for verifying that the bug is fixed!
Note You need to log in before you can comment on or make changes to this bug.