[webkit-changes] [WebKit/WebKit] 1a1e7a: Live-ish resize sometimes pops to unexpected scrol...

Tim Horton noreply at github.com
Thu Jan 5 17:48:41 PST 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1a1e7ad8f8a74fe4c00d54149795b14ee5626e3a
      https://github.com/WebKit/WebKit/commit/1a1e7ad8f8a74fe4c00d54149795b14ee5626e3a
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-01-05 (Thu, 05 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  -----------
  Live-ish resize sometimes pops to unexpected scroll position even if layout width doesn't change
https://bugs.webkit.org/show_bug.cgi?id=250153
rdar://96702143

Reviewed by Wenson Hsieh.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _updateScrollViewForTransaction:]):
By default, UIScrollView pins the center of the view when you change zoomScale.
When doing a live resize with a fixed layout width, the zoomScale changes on
every resize. Resizes normally pin the top edge of the content (or rather,
don't try to adjust the content offset -- at least until scroll anchoring
comes along), so this leads to surprising jumps. To fix this, when
web-process-originated scale changes occur, pin the vertical scroll position
to the top edge of the content, instead of the center. I don't expect any
clients are depending on the existing behavior, and hope that this
will be purely an improvement.

(-[WKWebView _didCommitLayerTree:]):
Like animated resize, bail from updating scroll view parameters and various
other incoming-commit-related things until *after* the live resize finishes.
This avoids us calling _updateScrollViewForTransaction and adjusting zoomScale
while the resize animation view is installed, which results in our scroll view
thinking that the current zoomScale is 1, and throwing all the math off, causing
further unexpected scrolling.

(-[WKWebView _updateVisibleContentRects]):
Fix this logging to indicate whether whether we're deferring geometry updates
for any reason; an earlier patch changed the condition but not the log.

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




More information about the webkit-changes mailing list