Bug 199488 - WKWebView fails to render when another view uses CoreImage filters
Summary: WKWebView fails to render when another view uses CoreImage filters
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Macintosh macOS 10.14
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-07-03 19:17 PDT by Dan Saunders
Modified: 2019-07-08 12:54 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.02 KB, patch)
2019-07-08 12:05 PDT, Tim Horton
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Saunders 2019-07-03 19:17:41 PDT
In 10.15 we noticed a regression where WKWebView was not rendering in our application and just shows a blank view. In 10.14.5 WKWebView is rendering with the same code. The issue is that when any subview in your window uses CoreImage filters, it breaks future WKWebView that are added to the window from rendering. I am not sure what change in WebKit caused this to stop working, but I can repro by running the latest WebKit code on my 10.14.5 machine. This does not repro when you change the order and first call -[WKWebView loadRequest:] before adding the web view to the window.

NSView *ciLayerView = [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 1, 1)];
ciLayerView.wantsLayer = YES;
ciLayerView.layerUsesCoreImageFilters = YES;
[[self view] addSubview:ciLayerView];

dispatch_async(dispatch_get_main_queue(), ^{
	WKWebView *webView = [[WKWebView alloc] initWithFrame:NSMakeRect(100, 100, 400, 400)];
	[self.view addSubview:webView];
	[webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.bing.com"]]];
});
Comment 1 Dan Saunders 2019-07-05 15:21:32 PDT
I have debugged this more and found the cause of the regression, it seems the issue is that m_layerHostingMode is never set to LayerHostingMode::InProcess when CI filters are used. Previously the WebKit content process is already started when you add WKWebView to the window, so WebPageProxy::viewDidEnterWindow updates the layer hosting mode. With recent changes, WebPageProxy::dispatchActivityStateChange returns early because no process is started and the layer hosting mode is not set correctly. PageClientImpl::viewLayerHostingMode can get the correct value for the window, but it is just not set correctly on the content process in this scenario. CI filter forces in-proc rendering, WebKit will need to match the layer hosting mode of the window that is hosting it.
Comment 2 Radar WebKit Bug Importer 2019-07-05 15:21:52 PDT
<rdar://problem/52705268>
Comment 3 Tim Horton 2019-07-08 11:31:14 PDT
Maybe a regression from the delayed web process launch thing?
Comment 4 Tim Horton 2019-07-08 11:33:18 PDT
I think WebPageProxy::layerHostingModeDidChange() should not early-return if there's no process launched. Or rather, it should, but just before the message send; it should still update m_layerHostingMode, which is sent across in WebPageCreationParameters.
Comment 5 Tim Horton 2019-07-08 12:05:26 PDT
Created attachment 373653 [details]
Patch
Comment 6 Tim Horton 2019-07-08 12:05:36 PDT
Does fix it.
Comment 7 Chris Dumez 2019-07-08 12:21:04 PDT
Comment on attachment 373653 [details]
Patch

LGTM too.
Comment 8 Tim Horton 2019-07-08 12:49:50 PDT
I took a quick jaunt through the rest of WebPageProxy and didn't see any other similarly wrong functions.
Comment 9 WebKit Commit Bot 2019-07-08 12:54:56 PDT
Comment on attachment 373653 [details]
Patch

Clearing flags on attachment: 373653

Committed r247227: <https://trac.webkit.org/changeset/247227>
Comment 10 WebKit Commit Bot 2019-07-08 12:54:58 PDT
All reviewed patches have been landed.  Closing bug.