Bug 229403 – WKWebView: Major delays for composited value animations

• Component: Animations
• Status: RESOLVED FIXED

[Matt Perry]

Open either of these links in iOS Safari, and again in iOS Chrome:

WAAPI: https://8ozd3.csb.app/
CSS `animation`: https://4bg8j.csb.app/

In Safari, the animation plays immediately on page load, as expected.

In Chrome, only the non-composited value plays immediately (`background`). `transform` and `opacity` don't animate until several seconds after page load, and even then the animation is completely out of sync with `background`.

Interestingly, the `fill: backwards` does apply both values before they start animating, out of ignorance this suggests to me that they're operating on entirely different timelines or are given different `startTime` (although logging suggests the latter isn't the case).

[Matt Perry]

WAAPI source code: https://codesandbox.io/s/waapi-webkit-iteration-timing-bug-forked-8ozd3?file=/src/index.js
CSS `animate` source code: https://codesandbox.io/s/css-animation-webkit-iteration-timing-bug-forked-4bg8j?file=/src/styles.css:0-925

[Matt Perry]

Created attachment 436186 [details]
iPhone running 14.7.1 with long delay. Same every refresh

[Matt Perry]

Created attachment 436187 [details]
Different iPhone with short delay, same every refresh

[Matt Perry]

I tried the same link on my wife's iPhone and my iPhone and there are two different delay durations, but they remain the same after repeated refreshes. I've attached videos.

[Matt Perry]

Further experimentation:

On my iPhone, the composited animations take almost exactly 14 seconds to start. It isn't bound to `duration`; if `duration` is 2s then it'll start after 7 iterations, 15s partially into the second iteration.

The `animate` call can be wrapped in a timeout of this duration, when triggered it will take another 14s for the composited animations to start. So this doesn't seem bound to the global timeline.

Manually pausing the animation and driving it by setting `currentTime` in a `requestAnimationFrame` loop will fix the animation: 
https://fexji.csb.app/
Source: https://codesandbox.io/s/waapi-webkit-iteration-timing-bug-forked-fexji?file=/src/index.js:459-644

[Matt Perry]

Setting playbackRate to 1.000001 also fixes the animation.

[Matt Perry]

From looking into other related bugs it looks like playbackRate !== 1 is booting the animation off CA which makes sense as it also fixes Webkit's synchronisation issues.

[Radar WebKit Bug Importer]

<rdar://problem/82517366>

[Antoine Quint]

I'm on iOS 15 and haven't checked with iOS 14.7.1 yet, but I'm not seeing differences between Safari and Chrome here, nor do I between Safari and the simple WKWebView test app "WebView" (https://apps.apple.com/fr/app/webview-wkwebview-and-uiwebview-rendering/id928647773?l=en).

Have you had a chance to try an iOS 15 beta to see if the issue persists? I would be curious to know also if you can reproduce the issue with the various modes (UIWebView, WKWebView, SafariViewController) in the "WebView" app, even on iOS 14.7.1.

[Matt Perry]

(In reply to Antoine Quint from comment #9)
> I'm on iOS 15 and haven't checked with iOS 14.7.1 yet, but I'm not seeing
> differences between Safari and Chrome here, nor do I between Safari and the
> simple WKWebView test app "WebView"
> (https://apps.apple.com/fr/app/webview-wkwebview-and-uiwebview-rendering/
> id928647773?l=en).
> 
> Have you had a chance to try an iOS 15 beta to see if the issue persists? I
> would be curious to know also if you can reproduce the issue with the
> various modes (UIWebView, WKWebView, SafariViewController) in the "WebView"
> app, even on iOS 14.7.1.

I haven't had the chance but that sounds promising, perhaps a fix has filtered through. I wouldn't know where to start with the other Webkit APIs to be honest. But will look into upgrading to 15 beta.

[Matt Perry]

(In reply to Antoine Quint from comment #9)

> Have you had a chance to try an iOS 15 beta to see if the issue persists?

Yeah this does seem to be fixed in 15

[Antoine Quint]

(In reply to Matt Perry from comment #11)
> (In reply to Antoine Quint from comment #9)
> 
> > Have you had a chance to try an iOS 15 beta to see if the issue persists?
> 
> Yeah this does seem to be fixed in 15

Are you confirming that on iOS 15 you are seeing the same correct behavior in both Safari and Chrome?

If so, please change this bug's status to Resolved / Configuration Changed.

[Antoine Quint]

Mistakenly marked as resolved, but waiting on the orignal bug reporter to confirm this.

[Antoine Quint]

Reopening until we hear back from the orignal bug reporter.

[Matt Perry]

Can confirm fixed in Chrome in iOS 15, thanks