RESOLVED FIXED 165028
Reduce platform ifdefs in WebKit2 custom protocols implementation
https://bugs.webkit.org/show_bug.cgi?id=165028
Summary Reduce platform ifdefs in WebKit2 custom protocols implementation
Carlos Garcia Campos
Reported 2016-11-22 01:47:20 PST
There are several ifdefs for soup and cocoa that could be avoided with just some refactorings.
Attachments
WIP patch (27.94 KB, patch)
2016-11-22 01:52 PST, Carlos Garcia Campos
no flags
WIP with xcode changes (33.66 KB, patch)
2017-01-18 01:11 PST, Carlos Garcia Campos
no flags
WIP (37.39 KB, patch)
2017-01-18 01:37 PST, Carlos Garcia Campos
no flags
WIP (37.77 KB, patch)
2017-01-18 02:14 PST, Carlos Garcia Campos
no flags
WIP (39.15 KB, patch)
2017-01-18 02:30 PST, Carlos Garcia Campos
no flags
WIP (40.33 KB, patch)
2017-01-18 02:59 PST, Carlos Garcia Campos
no flags
Patch (44.25 KB, patch)
2017-01-18 05:03 PST, Carlos Garcia Campos
darin: review+
Rebased patch for landing (42.06 KB, patch)
2017-02-20 02:48 PST, Carlos Garcia Campos
no flags
Patch for landing (41.91 KB, patch)
2017-02-21 08:28 PST, Carlos Garcia Campos
no flags
Carlos Garcia Campos
Comment 1 2016-11-22 01:52:09 PST
Created attachment 295332 [details] WIP patch This patch adds CustomProtocolManagerProxy.cpp that is cross-platform and adds an API::CustomProtocolManagerClient implementation for cocoa. As usual, I need help with the Xcode changes, I could have removed the deleted files myself, but since there are new files someone with a Mac will have to edit the xcode file in any case.
Carlos Garcia Campos
Comment 2 2017-01-18 01:11:52 PST
Created attachment 299123 [details] WIP with xcode changes
Carlos Garcia Campos
Comment 3 2017-01-18 01:37:39 PST
Carlos Garcia Campos
Comment 4 2017-01-18 02:14:16 PST
Carlos Garcia Campos
Comment 5 2017-01-18 02:30:10 PST
Carlos Garcia Campos
Comment 6 2017-01-18 02:59:59 PST
Carlos Garcia Campos
Comment 7 2017-01-18 05:03:30 PST
Carlos Garcia Campos
Comment 8 2017-02-13 23:50:06 PST
Ping reviewers :-)
Darin Adler
Comment 9 2017-02-14 10:53:05 PST
Comment on attachment 299133 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=299133&action=review > Source/WebKit2/UIProcess/Cocoa/CustomProtocolManagerClient.h:46 > + void startLoading(CustomProtocolManagerProxy&, uint64_t /*customProtocolID*/, const WebCore::ResourceRequest&) override; > + void stopLoading(CustomProtocolManagerProxy&, uint64_t /*customProtocolID*/) override; > + void invalidate(CustomProtocolManagerProxy&) override; WebKit coding style says to use final, not override. > Source/WebKit2/UIProcess/Cocoa/CustomProtocolManagerClient.mmSource/WebKit2/UIProcess/Network/CustomProtocols/mac/CustomProtocolManagerProxyMac.mm:143 > + // FIXME: iterate the loader map and remove loaders for the given manager. Why is it safe to leave this unimplemented? > Source/WebKit2/UIProcess/WebProcessPool.cpp:371 > + for (const auto& scheme : globalURLSchemesWithCustomProtocolHandlers()) > + parameters.urlSchemesRegisteredForCustomProtocols.append(scheme); > + > + for (const auto& scheme : m_urlSchemesRegisteredForCustomProtocols) > + parameters.urlSchemesRegisteredForCustomProtocols.append(scheme); I suggest just auto& rather than const auto&.
Carlos Garcia Campos
Comment 10 2017-02-15 08:40:55 PST
(In reply to comment #9) > Comment on attachment 299133 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=299133&action=review Thanks for the review! > > Source/WebKit2/UIProcess/Cocoa/CustomProtocolManagerClient.h:46 > > + void startLoading(CustomProtocolManagerProxy&, uint64_t /*customProtocolID*/, const WebCore::ResourceRequest&) override; > > + void stopLoading(CustomProtocolManagerProxy&, uint64_t /*customProtocolID*/) override; > > + void invalidate(CustomProtocolManagerProxy&) override; > > WebKit coding style says to use final, not override. Even for a class already marked as final? > > Source/WebKit2/UIProcess/Cocoa/CustomProtocolManagerClient.mmSource/WebKit2/UIProcess/Network/CustomProtocols/mac/CustomProtocolManagerProxyMac.mm:143 > > + // FIXME: iterate the loader map and remove loaders for the given manager. > > Why is it safe to leave this unimplemented? Because it's a refactoring, this is already unimplemented with current code. I was afraid of breaking something trying to implement this, since I'm not familiar with how custom protocols work in Mac and I don't have a way to test it. So, I think it's better if someone who knows this code can implement this afterwards. > > Source/WebKit2/UIProcess/WebProcessPool.cpp:371 > > + for (const auto& scheme : globalURLSchemesWithCustomProtocolHandlers()) > > + parameters.urlSchemesRegisteredForCustomProtocols.append(scheme); > > + > > + for (const auto& scheme : m_urlSchemesRegisteredForCustomProtocols) > > + parameters.urlSchemesRegisteredForCustomProtocols.append(scheme); > > I suggest just auto& rather than const auto&. Ok.
Michael Catanzaro
Comment 11 2017-02-15 09:11:38 PST
(In reply to comment #10) > > WebKit coding style says to use final, not override. > > Even for a class already marked as final? I strongly prefer override to final because it's much more descriptive and it doesn't seem particularly useful to prohibit overriding particular methods. But yes, we discussed it on webkit-dev a while back and IIRC agreed to use final in all cases except where the function needs to be overridden a second time, for better or for worse. We've been ignoring that in our GTK+ patches but should probably start using it.
Carlos Garcia Campos
Comment 12 2017-02-20 02:48:53 PST
Created attachment 302130 [details] Rebased patch for landing
WebKit Commit Bot
Comment 13 2017-02-20 04:29:45 PST
Comment on attachment 302130 [details] Rebased patch for landing Clearing flags on attachment: 302130 Committed r212632: <http://trac.webkit.org/changeset/212632>
WebKit Commit Bot
Comment 14 2017-02-20 04:29:50 PST
All reviewed patches have been landed. Closing bug.
Ryan Haddad
Comment 15 2017-02-20 10:09:52 PST
This change appears to have caused 21 API test failures/timeouts: https://build.webkit.org/builders/Apple%20Sierra%20Release%20WK2%20%28Tests%29/builds/3724
Carlos Garcia Campos
Comment 16 2017-02-20 10:14:58 PST
(In reply to comment #15) > This change appears to have caused 21 API test failures/timeouts: > > https://build.webkit.org/builders/ > Apple%20Sierra%20Release%20WK2%20%28Tests%29/builds/3724 hmm, I'm sorry, I'm surprised it causes failures in tests other than the custom protocols one, that is failing too. Anyway, feel free to roll it out, and I'll try to find time to look at it again in more detail.
Ryan Haddad
Comment 17 2017-02-20 10:18:34 PST
Reverted r212632 for reason: This change appears to have caused API test failures. Committed r212655: <http://trac.webkit.org/changeset/212655>
Carlos Garcia Campos
Comment 18 2017-02-21 08:24:27 PST
Ok, found the issue, git rebase messed it up, adding setCustomProtocolManagerClient() call to WebProcessPool::updateProcessSuppressionState() instead of WebProcessPool::platformInitialize() :-/ I'll submit a new patch for landing.
Carlos Garcia Campos
Comment 19 2017-02-21 08:28:03 PST
Created attachment 302262 [details] Patch for landing
WebKit Commit Bot
Comment 20 2017-02-21 10:26:37 PST
Comment on attachment 302262 [details] Patch for landing Clearing flags on attachment: 302262 Committed r212724: <http://trac.webkit.org/changeset/212724>
WebKit Commit Bot
Comment 21 2017-02-21 10:26:42 PST
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.