[Webkit-unassigned] [Bug 142583] New: The app with several WKWebView freezes when restoring from background

[bugzilla-daemon at webkit.org]

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

            Bug ID: 142583
           Summary: The app with several WKWebView freezes when restoring
                    from background
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: iOS
               URL: https://yadi.sk/d/Pi04ndh9f5TWh
                OS: iOS 8.2
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: stone33.mail at gmail.com

Created attachment 248424
  --> https://bugs.webkit.org/attachment.cgi?id=248424&action=review
Sample project

The bug is related to WKWebView iOS component, actual version on iOS 8.2 is 600.1.4


Short description:
Having many WKWebView instances the restoration from background can freeze for several seconds, while waiting for IPC (this behaviour is not expected and is much different from UIWebView. I should mention here that the bug is also reproducable on mobile Safari).
In WKContentView.mm we can see the code:

- (void)_applicationWillEnterForeground:(NSNotification*)notification
{
    ...
    _page->viewStateDidChange(ViewState::AllFlags & ~ViewState::IsInWindow, ***true***, WebPageProxy::ViewStateChangeDispatchMode::Immediate);
}

where the boolean parameter indicates that the IPC call should be handled synchronously.


There is a bugreport to Apple describing the same problem: http://openradar.appspot.com/20068553

Summary:
In the apps that use many WKWebView instances there is a problem with restoration from background which leads to UI freezing or even killing by system (because of not resuming in certain time interval). The problem affects Safari on iOS 8, as well.

If most of web view instances are not in view hierarchy when entering background and restoring back - restoration is always slow, even if you push "Home" and return back to your app without switching to another tasks.
If you switch to another apps, especially memory-demanding or using WKWebViews such as Safari and then return back to you app (make sure it was not unloaded by the system) - you get main thread completely freezed by communicating with WKWebView system process. This problem has a huge user experience impact and also can lead to a crash due to not resuming in time.

Steps to Reproduce:
Use the attached sample project

Case 1.
1. Load 5-10 WKWebView instances using "Create" button.
2. Press "Home", wait several seconds
3. Return to the app and see a restoration time - should be 1-4 seconds with the linear dependence on the web view instances count.

Case 2.
1. Same as before
2. Tap the "Workaround" button. This puts all WKWebView instances into view hierarchy.
2. Press "Home", wait several seconds
3. Return to the app and see a restoration time - should less than a second.
4. Switch to another apps, browse sites in Safari, etc.
5. Switch to the sample app again - restoration time should be several seconds again.

Expected Results:
Main thread is not blocked or blocked only for the active WKWebView instance

Actual Results:
Inter-process communication freezing main thread is performed for all WKWebView instances, so the restoration time is completely unacceptable (if keeping in mind a UI responsiveness principle).

Version:
iOS 8.1.3 [12B466], 8.2 [12D508], 8.3 beta 2 [12F5037c]

Notes:


Configuration:
iPhone 5s, iPhone 6, iPad mini

Attachments:
'WKWebViewRestorationFromBackground.zip': https://yadi.sk/d/Pi04ndh9f5TWh

-- 
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/20150311/9055d4b0/attachment-0002.html>