WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Updated patch
(25.69 KB, patch)
2014-01-26 06:25 PST
,
Carlos Garcia Campos
gustavo
: 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
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
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
Committed
r162920
: <
http://trac.webkit.org/changeset/162920
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug