Comment 8 for bug 1260016

This is fixed with http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/787. Note that there are some significant differences between this and the equivalent qtwebkit API, notably:

- The API is on WebContext rather than WebView.

- You don't register individual handlers for responding to network requests. Instead, you set a list of custom URL schemes on WebContext.allowedExtraUrlSchemes, and then Oxide uses the QNetworkAccessManager provided by the QQmlEngine. To set a custom QNetworkAccessManager, you'll need to implement QQmlNetworkAccessManagerFactory and assign this to the QQmlEngine associated with the QQuickView that your webview is in. If you want to share the QNAM with other parts of the application, then you'll need to make sure it outlives the QQmlEngine.

- Oxide takes care of proxying the data from QNetworkAccessManager + QNetworkReply on the UI thread to Chromium's network stack on its IO thread (see http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/shared/base/oxide_cross_thread_data_stream.cc and http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/core/browser/oxide_qt_url_request_delegated_job.cc). You don't need to implement this manually in the application.

- You can't override standard protocol schemes (http/https/ws/wss/file etc). This is deliberate for a few reasons:
a. Custom schemes need to interact with the UI thread, whereas using Chromium's network stack doesn't.
b. We can decide asynchronously on the UI thread whether to ignore SSL errors from Chromium's network stack. However, Qt requires that we call QNetworkReply::ignoreSslErrors from inside the slot connected to QNetworkReply::sslErrors, which means we can't respond asynchronously (we'd need to block the UI thread whilst the IO thread posts a task to the blocked UI thread for handling the error, which obviously isn't possible). This means that errors from custom handlers can't be integrated with the WebView.certificateError signal.
c. We can't really construct the HTTP response on the Chromium side without having access to the raw response header.

As you already implement a custom QNetworkAccessManager in dekko, this API should work for you without too much effort (and you can get rid of QQuickNetworkReplyWrapper).