ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

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).

** Changed in: oxide
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1260016

Title:
  Add an API to allow defining custom URL scheme delegates

Status in dekko:
  Triaged
Status in Oxide Webview:
  Fix Released
Status in “oxide-qt” package in Ubuntu:
  In Progress
Status in “oxide-qt” package in Ubuntu RTM:
  In Progress

Bug description:
  For feature parity with QtWebKit, the QML WebView needs a way to allow
  application developers to define custom URL scheme delegates (in
  QtWebKit, the property is 'experimental.urlSchemeDelegates', of type
  list).

To manage notifications about this bug go to:
https://bugs.launchpad.net/dekko/+bug/1260016/+subscriptions