RESOLVED FIXED 189012
Make WebPageProxy always have a API::NavigationClient instead of always having a API::LoaderClient and API::PolicyClient
https://bugs.webkit.org/show_bug.cgi?id=189012
Summary Make WebPageProxy always have a API::NavigationClient instead of always havin...
Alex Christensen
Reported 2018-08-27 15:09:32 PDT
Make WebPageProxy always have a API::NavigationClient instead of always having a API::LoaderClient and API::PolicyClient
Attachments
Patch (31.57 KB, patch)
2018-08-27 15:10 PDT, Alex Christensen
no flags
Patch (30.93 KB, patch)
2018-09-17 13:11 PDT, Alex Christensen
no flags
Patch (32.63 KB, patch)
2018-09-17 13:31 PDT, Alex Christensen
no flags
Patch (33.45 KB, patch)
2018-09-17 14:34 PDT, Alex Christensen
no flags
Patch (34.34 KB, patch)
2018-09-18 11:42 PDT, Alex Christensen
aestes: review+
Alex Christensen
Comment 1 2018-08-27 15:10:38 PDT
Alex Christensen
Comment 2 2018-09-17 13:11:19 PDT
Alex Christensen
Comment 3 2018-09-17 13:31:44 PDT
EWS Watchlist
Comment 4 2018-09-17 13:34:05 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Alex Christensen
Comment 5 2018-09-17 14:34:44 PDT
youenn fablet
Comment 6 2018-09-17 21:29:54 PDT
Comment on attachment 349942 [details] Patch Can the change log contain some explanations about the change of order between calls to NavigationClient and LoaderClient/PolicyClient. In the case of navigation loads, it makes sense to me NavigationClient should be called even if LoaderClient is set. View in context: https://bugs.webkit.org/attachment.cgi?id=349942&action=review > Source/WebKit/UIProcess/WebPageProxy.cpp:3492 > m_loaderClient->didStartProvisionalLoadForFrame(*this, *frame, navigation.get(), m_process->transformHandlesToObjects(userData.object()).get()); Isn't it a behavioral change here? Previously, whenever we had a m_navigationClient, we were never calling m_loaderClient->didStartProvisionalLoadForFrame. Shouldn't we revert the test so that we continue calling didStartProvisionalNavigation for main frames and call didStartProvisionalLoadForFrame for other frames if loader client is there? > Source/WebKit/UIProcess/WebPageProxy.cpp:3525 > + m_navigationClient->didReceiveServerRedirectForProvisionalNavigation(*this, navigation.get(), m_process->transformHandlesToObjects(userData.object()).get()); Ditto here and below. > Source/WebKit/UIProcess/WebPageProxy.cpp:6922 > + if (RefPtr<API::Data> keyData = m_navigationClient->webCryptoMasterKey(*this)) auto here and below.
Alex Christensen
Comment 7 2018-09-18 11:41:52 PDT
Comment on attachment 349942 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=349942&action=review >> Source/WebKit/UIProcess/WebPageProxy.cpp:3492 >> m_loaderClient->didStartProvisionalLoadForFrame(*this, *frame, navigation.get(), m_process->transformHandlesToObjects(userData.object()).get()); > > Isn't it a behavioral change here? > Previously, whenever we had a m_navigationClient, we were never calling m_loaderClient->didStartProvisionalLoadForFrame. > Shouldn't we revert the test so that we continue calling didStartProvisionalNavigation for main frames and call didStartProvisionalLoadForFrame for other frames if loader client is there? This is not a meaningful change in behavior. All clients with a LoaderClient do not use a NavigationClient. Preferring the LoaderClient just makes us not break those legacy clients until they migrate to using WKPageSetPageNavigationClient. Modern clients use a NavigationClient, and this is making that the default without breaking legacy software.
Alex Christensen
Comment 8 2018-09-18 11:42:36 PDT
Alex Christensen
Comment 9 2018-09-18 14:03:44 PDT
Radar WebKit Bug Importer
Comment 10 2018-09-18 14:04:50 PDT
Note You need to log in before you can comment on or make changes to this bug.