[iOS] CSS transform transitions become janky after snapshotting other UIViews

[graouts]

46c1b78

[iOS] CSS transform transitions become janky after snapshotting other UIViews
https://bugs.webkit.org/show_bug.cgi?id=228333
rdar://81165591

Reviewed by Dean Jackson.

In WebKit clients that use the UIView snapshotting API, accelerated animations, which
are ran using Core Animation, will not run anymore. This happens because we use absolute
start times for our CAAnimation objects, and this does not play well with the UIView
snapshotting machinery.

Using the -[CALayer setInheritsTiming:(BOOL)] private API addresses this issue, so we call
it with NO any time we add a CAAnimation to a remote layer.

* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCAAnimationRemote.mm:
(WebKit::addAnimationToLayer):

Canonical link: https://commits.webkit.org/258781@main

ee8e032

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	❌ 🛠 🧪 win
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	❌ 🛠 gtk	🛠 wincairo
✅ 🧪 webkitperl	🧪 ios-wk2	🧪 api-mac	❌ 🧪 gtk-wk2
	🧪 api-ios	🧪 mac-wk1	❌ 🧪 api-gtk
	✅ 🛠 tv	🧪 mac-wk2
	✅ 🛠 tv-sim	🧪 mac-AS-debug-wk2
	✅ 🛠 watch	🧪 mac-wk2-stress
	✅ 🛠 watch-sim
✅ 🛠 🧪 unsafe-merge

[webkit-early-warning-system]

EWS run on previous version of this PR (hash b179025)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 🧪 win
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🛠 gtk	✅ 🛠 wincairo
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 gtk-wk2
	✅ 🧪 api-ios	❌ 🧪 mac-wk1	✅ 🧪 api-gtk
	✅ 🛠 tv	✅ 🧪 mac-wk2
	✅ 🛠 tv-sim	✅ 🧪 mac-AS-debug-wk2
	✅ 🛠 watch	✅ 🧪 mac-wk2-stress
	✅ 🛠 watch-sim

[grorg]

Can we test this?

[webkit-early-warning-system]

EWS run on previous version of this PR (hash 8e8d154)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 🧪 win
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🛠 gtk	✅ 🛠 wincairo
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 gtk-wk2
	✅ 🧪 api-ios	❌ 🧪 mac-wk1	✅ 🧪 api-gtk
	✅ 🛠 tv	✅ 🧪 mac-wk2
	✅ 🛠 tv-sim	✅ 🧪 mac-AS-debug-wk2
	✅ 🛠 watch	✅ 🧪 mac-wk2-stress
	✅ 🛠 watch-sim

[webkit-early-warning-system]

EWS run on current version of this PR (hash ee8e032)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	❌ 🛠 🧪 win
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	❌ 🛠 gtk	🛠 wincairo
✅ 🧪 webkitperl	🧪 ios-wk2	🧪 api-mac	❌ 🧪 gtk-wk2
	🧪 api-ios	🧪 mac-wk1	❌ 🧪 api-gtk
	✅ 🛠 tv	🧪 mac-wk2
	✅ 🛠 tv-sim	🧪 mac-AS-debug-wk2
	✅ 🛠 watch	🧪 mac-wk2-stress
	✅ 🛠 watch-sim
✅ 🛠 🧪 unsafe-merge

[graouts]

Can we test this?

I think in theory it is possible exercising the -[UIView snapshotAfterScreenUpdates:] or -[UIView resizableSnapshotViewFromRect:afterScreenUpdates:withCapInsets:] in an API test. However, I haven't been able to find a solid way to reproduce the issue using those API calls. The reports we've had of this issue highlight that the issue varies based on the view hierarchy complexity and the number of calls made to such methods.

[webkit-commit-queue]

Committed 258781@main (46c1b78): https://commits.webkit.org/258781@main

Reviewed commits have been landed. Closing PR #8394 and removing active labels.