[webkit-changes] [WebKit/WebKit] d517e2: Changing WKScrollView's scale during animated resi...

[Tim Horton]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d517e2b34c072bfef2c557c912e365beb8475526
      https://github.com/WebKit/WebKit/commit/d517e2b34c072bfef2c557c912e365beb8475526
  Author: Tim Horton <thorton at apple.com>
  Date:   2022-12-23 (Fri, 23 Dec 2022)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/AnimatedResize.mm

  Log Message:
  -----------
  Changing WKScrollView's scale during animated resize causes permanent WKContentView offset
https://bugs.webkit.org/show_bug.cgi?id=249818
rdar://102780985

Reviewed by Wenson Hsieh.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView viewForZoomingInScrollView:]):
During animated (and live-ish) resize, we install a transform-only view between
WKScrollView and WKContentView. If during this time the WKScrollView is
asked to change its scale, UIScrollView code tries to maintain the origin of
WKContentView (the viewForZooming), but ends up moving the WKContentView's
frame origin away from (0, 0) to do so. Nothing ever comes along and fixes up
WKContentView's frame origin, so the top left corner of the content comes
permanently detached from the top left xorner of the scroll view.

To avoid this, prevent scaling while the resizeAnimationView is installed.
We want to own the scale ourselves (that's the whole point of resizeAnimationView),
and will apply scale changes in the transaction that results in the removal
of the resizeAnimationView. And it doesn't really make sense to allow user-driven
scaling during this time, either (and doesn't work right at all).

* Tools/TestWebKitAPI/Tests/WebKitCocoa/AnimatedResize.mm:
(TEST):
Add a test that ensures that WKContentView's frame origin doesn't get thrown off
by changing the WKScrollView's scale while the resizeAnimationView is installed.

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