[Webkit-unassigned] [Bug 283794] WebContent shared process bug when building WebKit using Xcode 16

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=283794

Ben Nham <nham at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #4 from Ben Nham <nham at apple.com> ---
As Alexey wrote, some new features are only enabled when your app links against a new version of the SDK (e.g. the iOS 18 SDK instead of the iOS 17.4 SDK). In this particular case, almost certainly the thing that is causing your content to behave differently after linking against the iOS 18 SDK is SDKAlignedBehavior::FullySuspendsBackgroundContentImmediately, which was enabled as part of this patch set: https://commits.webkit.org/272937@main.

Basically, previously we would wait 8 minutes before suspending the WebContent process associated with a background WKWebView. (A WKWebView not attached to the view hierarchy would be considered a background web view.) In iOS 18, we are more prompt about suspending those processes. For most cases this is fine, since WebKit will unsuspend the process to e.g. handle page loads until the load event fires, or to handle `-evaluteJavaScript:completIionHandler:` calls, etc.

If your use case actually really requires running the content in a background WKWebView continuously, then use this API to change the background throttling settings of the web view: https://developer.apple.com/documentation/webkit/wkpreferences/inactiveschedulingpolicy-swift.property. Set the property to WKInactiveSchedulingPolicyThrottle (preferable for battery life reasons), or WKInactiveSchedulingPolicyNone. The default is WKInactiveSchedulingPolicySuspend, which as the docs state, is a policy where "a policy where a web view that’s not in a window fully suspends tasks."

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20241203/ce4a39a6/attachment.htm>