Bug 131860 – [iOS] REGRESSION (r167039): WebKit incorrectly sets a background process assertion state when displaying a PDF

• Component: New Bugs
• Status: RESOLVED FIXED

[Andy Estes]

[iOS] REGRESSION (r167039): WebKit incorrectly sets a background process assertion state when displaying a PDF

[Andy Estes]

<rdar://problem/16631282>

[Andy Estes]

Created attachment 229678 [details]
Patch

[Tim Horton]

Comment on attachment 229678 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=229678&action=review

> Source/WebKit2/UIProcess/ios/PageClientImplIOS.mm:130
> -    return [m_contentView window];
> +    return [m_webView window];

We also need to notify the view state that it needs to recompute when WKWebView goes into/out of window, just like WKContentView does:
WKWebView

- (void)didMoveToWindow
{
    _page->viewStateDidChange(ViewState::IsInWindow);
}

[Tim Horton]

Comment on attachment 229678 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=229678&action=review

>> Source/WebKit2/UIProcess/ios/PageClientImplIOS.mm:130
>> +    return [m_webView window];
> 
> We also need to notify the view state that it needs to recompute when WKWebView goes into/out of window, just like WKContentView does:
> WKWebView
> 
> - (void)didMoveToWindow
> {
>     _page->viewStateDidChange(ViewState::IsInWindow);
> }

And the reason is, we want to background e.g. the network process if you have a PDF currently loaded and then remove the WKWebView (so the WKContentView didMoveToWindow won't get called, and won't viewStateDidChange, so WKWebView has to do it). There's also no real reason to do it in WKContentView's didMoveToWindow, since it will only change on WKWebView's.

[Andy Estes]

Committed r167512: <http://trac.webkit.org/changeset/167512>