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.
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.
Created attachment 222201 [details] Patch Note that this doesn't affect EFL because they don't use the initiatingPageID.
Created attachment 222270 [details] Updated patch
Comment on attachment 222270 [details] Updated patch yay
Created attachment 222318 [details] Patch for landing Want to make sure I haven't broken EFL.
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
Committed r162920: <http://trac.webkit.org/changeset/162920>