Deprecation notice: SilicaWebView, QtWebKit

As some of you may have noticed from the Sailfish OS 4.4.0 Vanha Rauma release notes, using QtWebKit (or the SilicaWebView wrapper for it) in an app will now trigger a deprecation warning in the logs, like this:

[D] onCompleted:180 - SilicaWebView is deprecated from Sailfish 4.4.0 
onwards and will be removed in a future release, use Sailfish WebView 
instead. See 
https://sailfishos.org/develop/docs/sailfish-components-webview/

We plan to remove SilicaWebView and QtWebKit so that they’re no longer allowed in harbour in an upcoming release.

If you’re an app developer and one of your apps makes use of a SilicaWebView, now would therefore be a really good time to start transitioning your app to use the Sailfish WebView API instead.

The new WebView API harnesses the gecko renderer which is more modern and more compatible. This will improve your users’ experience, but also help avoid potential security vulnerabilities.

And while the SilicaWebView and Sailfish WebView APIs aren’t identical, they provide similar and overlapping functionality. For most developers, converting your app to use the new WebVew should be a relatively straightforward task.

Let’s work through an example. Here’s what a typical page containing a SilicaWebView might look like. Notice that there are a number of experimental options, some of which are pretty much necessary to provide a good result (such as the width and height settings), and some of which may only be needed for specific reasons (such as the user agent setting).

import QtQuick 2.0
import Sailfish.Silica 1.0
import QtWebKit 3.0
import QtWebKit.experimental 1.0

Page {
    allowedOrientations: Orientation.All

    SilicaWebView {
        anchors.fill: parent
        url: "http://www.sailfishos.org"

        experimental.temporaryCookies: true
        experimental.userAgent: "Mozilla/5.0 (Mobile Linux; U; like"
            + " Android 4.4.3; Sailfish OS/2.0) AppleWebkit/535.19 (KHTML,"
            + " like Gecko) Version/4.0 Mobile Safari/535.19"
        experimental.autoCorrect: false
        experimental.deviceWidth: parent.width
        experimental.deviceHeight: parent.height
    }
}

Here’s how the equivalent code looks when the SilicaWebView has been replaced with a Sailfish WebView component.

import QtQuick 2.0
import Sailfish.Silica 1.0
import Sailfish.WebView 1.0
import Sailfish.WebEngine 1.0
import Sailfish.WebView.Popups 1.0

Page {
    allowedOrientations: Orientation.All

    WebView {
        anchors.fill: parent
        url: "http://www.sailfishos.org"
        privateMode: true
        httpUserAgent: "Mozilla/5.0 (Mobile; rv:78.0) Gecko/78.0"
            + " Firefox/78.0"

        popupProvider: PopupProvider {
             // Disable the Save Password dialog
             passwordManagerPopup: null
        }
    }
}

You can also see the full diff between the two in the example’s repository on github.

Some of the differences to note:

  • In the updated version we use private mode rather than setting a temporary cookie store.
  • The experimental.userAgent property is now httpUserAgent, but in practice there should be less need to use this with the updated engine.
  • In the second case we set a null passwordManagerPopup. This prevents the app from asking whether it should save the user’s password. This is optional, but probably sensible for many apps.

If you check the diff you’ll notice we also added some new runtime dependences to the spec file.

Requires:   qtmozembed-qt5
Requires:   sailfish-components-webview-qt5
Requires:   sailfish-components-webview-qt5-popups
Requires:   sailfish-components-webview-qt5-pickers

As you can see, the process of switching from one to the other isn’t entirely automatic, but is nevertheless pretty painless.

We’d love to hear about your experiences converting your apps, so please share them here in the replies. And if you run into any problems, don’t hesitate to post here and we’ll do our best to help.

10 Likes

First thanks for the new Sailfish WebView API. To make it a little more better here some of my experience with the new API. I added Sailfish WebView API as second machine to my browser app Ielig:Web last year in october.

  1. The new API is much better for all the new trendy features
  2. As in the example above in most case the text will presented enhanced but it is impossible to zoom out more then the starting size
  3. The Sailfish WebView API crashed randomly. This can happen direct with starting an url or some minutes later. In most case I can read some web pages before the crash. Crashes happens also when using the native mail client (using the same API?).
  4. I am not sure that there no remains in browser data after surfing e.g. this forum in the API private mode. To handle with this my app I will first delete the browser data directoy and then start an new session. There must be a better way. Can I now trust the private mode? Is there complete declaration of data stored after using the API?
  5. When switching javascript off (and this is my default setting) in the old API I can catch every embedded external url in a web page. The new API has also a signal which sounds like the signal in the old API for doing the trick. But in my test the new signal sleeps sometimes. Is there a new status?
    https://forum.sailfishos.org/t/sailfish-webview-signal-linkclicked-sleeps-sometimes/9189

I have some more nice-to-have ideas but the new API is great - when stable. Many thanks.

3 Likes