WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
199488
WKWebView fails to render when another view uses CoreImage filters
https://bugs.webkit.org/show_bug.cgi?id=199488
Summary
WKWebView fails to render when another view uses CoreImage filters
Dan Saunders
Reported
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
"]]]; });
Attachments
Patch
(2.02 KB, patch)
2019-07-08 12:05 PDT
,
Tim Horton
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Dan Saunders
Comment 1
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.
Radar WebKit Bug Importer
Comment 2
2019-07-05 15:21:52 PDT
<
rdar://problem/52705268
>
Tim Horton
Comment 3
2019-07-08 11:31:14 PDT
Maybe a regression from the delayed web process launch thing?
Tim Horton
Comment 4
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.
Tim Horton
Comment 5
2019-07-08 12:05:26 PDT
Created
attachment 373653
[details]
Patch
Tim Horton
Comment 6
2019-07-08 12:05:36 PDT
Does fix it.
Chris Dumez
Comment 7
2019-07-08 12:21:04 PDT
Comment on
attachment 373653
[details]
Patch LGTM too.
Tim Horton
Comment 8
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.
WebKit Commit Bot
Comment 9
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
>
WebKit Commit Bot
Comment 10
2019-07-08 12:54:58 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug