RESOLVED FIXED 127614
[GTK] Make webkit_uri_scheme_request_get_web_view() work with CustomProtocols
https://bugs.webkit.org/show_bug.cgi?id=127614
Summary [GTK] Make webkit_uri_scheme_request_get_web_view() work with CustomProtocols
Carlos Garcia Campos
Reported 2014-01-25 00:40:49 PST
It's currently broken, because the RemoteNetworkingContext doesn't implement initiatingPageID, see bug #125582. This is public API already used by applications (midori at least) that will crash if it returns NULL. The CustomProtocolManager is a supplemental of the networking process. It registers the custom schemes in the soup session, so that when soup loads a request for any registered scheme, the WebKitSoupRequestGeneric object is used. This generic soup request notifies the CustomProtocolManager which creates the request identifier (customProtocolID) and sends a message to the UI process to start the loading. At this point, there's no way to know which page is associated to this request. In the web process, where the networking context implements initiatingPageID(), the resource handle sets the page ID as user data of the SoupRequest and we can get the page ID from the WebKitSoupRequestGeneric object used. In the network process, there's no page ID associated to the soup request. So, the easiest solution would be to implement RemoteNetworkingContext::initiatingPageID(), but the patch to do that doesn't look like it will be accepted by reviewers, so we need to find another way to not break our public API.
Attachments
Patch (25.66 KB, patch)
2014-01-25 02:13 PST, Carlos Garcia Campos
no flags
Updated patch (25.69 KB, patch)
2014-01-26 06:25 PST, Carlos Garcia Campos
gustavo: review+
Patch for landing (25.87 KB, patch)
2014-01-27 05:12 PST, Carlos Garcia Campos
no flags
Carlos Garcia Campos
Comment 1 2014-01-25 00:46:50 PST
There's another solution that wouldn't need to change any cross-platform code: We could move the initiatingPageID to the ResourceRequest. In the willSendRequest callback we set the initiating page id (willSendRequest receives the frame, so we have the page) to the request we return. In ResourceHandle, when creating the soup request for the given request we attach the page id to the soup request the same way we are currently doing, but using the ResourceRequest instead of NetworkingContext. Then we can remove the initiatingPageID() method from NetworkingContext. I think this is actually moving the problem to another place, but at least we can implement it in platform specific code entirely.
Carlos Garcia Campos
Comment 2 2014-01-25 02:13:41 PST
Created attachment 222201 [details] Patch Note that this doesn't affect EFL because they don't use the initiatingPageID.
Carlos Garcia Campos
Comment 3 2014-01-26 06:25:50 PST
Created attachment 222270 [details] Updated patch
Gustavo Noronha (kov)
Comment 4 2014-01-27 04:52:16 PST
Comment on attachment 222270 [details] Updated patch yay
Carlos Garcia Campos
Comment 5 2014-01-27 05:12:56 PST
Created attachment 222318 [details] Patch for landing Want to make sure I haven't broken EFL.
WebKit Commit Bot
Comment 6 2014-01-27 05:13:37 PST
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
Carlos Garcia Campos
Comment 7 2014-01-27 23:47:36 PST
Note You need to log in before you can comment on or make changes to this bug.