- 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.
- 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).
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. allowedExtraUrl Schemes, and then Oxide uses the QNetworkAccessM anager provided by the QQmlEngine. To set a custom QNetworkAccessM anager, you'll need to implement QQmlNetworkAcce ssManagerFactor y 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 QNetworkAccessM anager + 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: :ignoreSslError s 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. certificateErro r signal.
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:
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 QNetworkAccessM anager in dekko, this API should work for you without too much effort (and you can get rid of QQuickNetworkRe plyWrapper) .