[webkit-qt] decidePolicyForNavigationAction QML API

[simon.hausmann at nokia.com]

Hi,

The DesktopWebView QML element has an API that corresponds to the ChromeClient's decidePolicyForNavigationAction (and work is under way in bug #69572 to implement the same API for the touch webview). The API is currently structured like this:

DesktopWebView {

    function navigationPolicyForUrl(url, button, modifiers) {
        // Make decision here
    }

}

I'd like to change this API for four reasons:

1) The double-mentioning of url in  *PolicyForUrl(url looks strange :)

2) It is only possible for instances for the QML element to decide on the policy.

3) The API is synchronous, while the underlying implementation in WebKit2/ChromeClient is asynchronous. So while the engine can do it, our API forces the application to make a synchronous decision.

4) Only the magical presence of the function with the right name makes it possible for applications to decide on the policy. Qt Creator cannot provide any assistance in terms of completion.


I'd like to propose the following alternative API instead, that addresses all four points:

The WebView component gets a signal navigationRequested (naturally the name is just a proposal) that provides a "NavigationRequest" object (that internally wraps a WKFramePolicyListenerRef) and which provides corresponding methods/slots for use/download/ignore. This changes the usage to the following pattern:

DesktopWebView {
    id: view

}

Connections {
    target: view
    onNavigationRequested: {
         // ...
         request.accept();
    }
}

Note how the decision can be made anywhere in QML, it is up to the application whether to respond synchronously or asynchronously and Qt Creator offers signal completion for the signal when typing.


What do you think?

Simon