[Webkit-unassigned] [Bug 127614] New: [GTK] Make webkit_uri_scheme_request_get_web_view() work with CustomProtocols
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Jan 25 00:43:22 PST 2014
https://bugs.webkit.org/show_bug.cgi?id=127614
Summary: [GTK] Make webkit_uri_scheme_request_get_web_view()
work with CustomProtocols
Product: WebKit
Version: 528+ (Nightly build)
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Keywords: Gtk
Severity: Normal
Priority: P2
Component: WebKit2
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: cgarcia at igalia.com
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.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list