Bug 127614 - [GTK] Make webkit_uri_scheme_request_get_web_view() work with CustomProtocols
Summary: [GTK] Make webkit_uri_scheme_request_get_web_view() work with CustomProtocols
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 127091
  Show dependency treegraph
 
Reported: 2014-01-25 00:40 PST by Carlos Garcia Campos
Modified: 2014-01-27 23:47 PST (History)
8 users (show)

See Also:


Attachments
Patch (25.66 KB, patch)
2014-01-25 02:13 PST, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Updated patch (25.69 KB, patch)
2014-01-26 06:25 PST, Carlos Garcia Campos
gns: review+
Details | Formatted Diff | Diff
Patch for landing (25.87 KB, patch)
2014-01-27 05:12 PST, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 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.
Comment 1 Carlos Garcia Campos 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.
Comment 2 Carlos Garcia Campos 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.
Comment 3 Carlos Garcia Campos 2014-01-26 06:25:50 PST
Created attachment 222270 [details]
Updated patch
Comment 4 Gustavo Noronha (kov) 2014-01-27 04:52:16 PST
Comment on attachment 222270 [details]
Updated patch

yay
Comment 5 Carlos Garcia Campos 2014-01-27 05:12:56 PST
Created attachment 222318 [details]
Patch for landing

Want to make sure I haven't broken EFL.
Comment 6 WebKit Commit Bot 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
Comment 7 Carlos Garcia Campos 2014-01-27 23:47:36 PST
Committed r162920: <http://trac.webkit.org/changeset/162920>