Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d16baa5d785797e77476004365f8df27832fee70
https://github.com/WebKit/WebKit/commit/d16baa5d785797e77476004365f8df27832fee70
Author: Wenson Hsieh <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/ios/UIKitUtilities.mm
Log Message:
-----------
REGRESSION (296485@main): Wikipedia can get into a weird state after long
pressing on certain video links
https://bugs.webkit.org/show_bug.cgi?id=295672
rdar://154793516
Reviewed by Abrar Rahman Protyasha.
After the changes in 296485@main, long-pressing a link to a video that triggers
the fullscreen AVKit
player and then dismissing the view controller causes `WKWebView` to get into a
state where the
dimensions of its inner `WKScrollView` are much, much larger than intended.
This happens because `UIScrollView.topEdgeEffect.style` is internally backed by
`@Observable` state
in UIKit; when anything *reads* this state or changes it, UIKit observation
tracking logic is
scheduled on the next update cycle, triggering various workloads (in this bug,
`-layoutSubviews`).
This, in turn, may cause views in the view hierarchy (in this case,
Safari-owned views) to lay out
subviews based on out-of-date or inconsistent geometry.
To fix this, we refactor this logic to be more judicious when checking
`topEdgeEffect.style`, such
that we only invoke this getter during the next layer tree commit (instead of
immediately when
scrolling or changing adjusted content insets). This is probably a much safer
place, because:
- The rest of the view hierarchy is being updated anyways, and...
- Many other aspects of scroll view geometry are changed underneath this
codepath.
As a nice byproduct of this refactoring, we will now avoid thrashing the state
of
`_needsTopScrollPocketDueToVisibleContentInset` in cases where the content
offset and content inset
are changing at the same time, in such a way that the scroll view is
temporarily scrolled beyond the
top extent.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _didCommitLayerTree:]):
Invoke `_updateNeedsTopScrollPocketDueToVisibleContentInset` during the layer
tree commit, when the
rest of the scroll view's geometry is being updated anyways.
(-[WKWebView _updateNeedsTopScrollPocketDueToVisibleContentInset]):
Make this method a no-op unless the new
`_shouldUpdateNeedsTopScrollPocketDueToVisibleContentInset`
flag has been set.
(-[WKWebView scrollViewDidChangeAdjustedContentInset:]):
(-[WKWebView scrollViewDidScroll:]):
Instead of directly calling
`-_updateNeedsTopScrollPocketDueToVisibleContentInset`, set a new flag
to indicate that we should recompute the state during the next layer tree
commit, when the entire
view hierarchy is also being updated at the same time. See above for more
details.
* Source/WebKit/UIProcess/ios/UIKitUtilities.mm:
(-[UIScrollView _wk_usesHardTopScrollEdgeEffect]):
Add a comment warning that this method might cause layout issues if invoked at
the wrong time. Note
that there is one remaining call site when an element is focused; in my
testing, this seems to be
safe, because element focus triggers view layout anyways as input views are
reloaded.
Canonical link: https://commits.webkit.org/297197@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
