Bug 198564 – [WPE][GTK] Clean up use of initiatingPageID in implementation of webkit_uri_scheme_request_get_web_view()

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

webkit_uri_scheme_request_get_web_view() currently has illegal code to return NULL:

WebKitWebView* webkit_uri_scheme_request_get_web_view(WebKitURISchemeRequest* request)
{
    g_return_val_if_fail(WEBKIT_IS_URI_SCHEME_REQUEST(request), 0);

    // FIXME: initiatingPage is now always null, we need to re-implement this somehow.
    return request->priv->initiatingPage ? webkitWebContextGetWebViewForPage(request->priv->webContext, request->priv->initiatingPage.get()) : nullptr;
}

This is illegal because the return value is not nullable.

Since bug #198485, this code can no longer be reached, because for initiatingPage to be unset, we would have to dereference a disengaged Optional resourceRequest.initiatingPageID() in webkitURISchemeRequestCreate.

But Chris points out that it was probably already unreachable because, prior to bug #198485, the code would have called webPage() with 0, which "would have crashed since it would try and look up 0 in a HashMap whose key type is uint64_t."

So it seems the page ID is guaranteed to be valid at this point, even though the FIXME comment indicates it is never valid. Probably makes sense to replace all this with an ASSERT. I don't plan to investigate this further.

[Michael Catanzaro]

Created attachment 371394 [details]
Patch

[EWS Watchlist]

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

[WebKit Commit Bot]

Comment on attachment 371394 [details]
Patch

Clearing flags on attachment: 371394

Committed r246152: <https://trac.webkit.org/changeset/246152>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.