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.

11 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

I’m getting a reject in the Store:

No OS version and packages satisfy package requirements: 
Requirement sailfish-components-webview-qt5-pickers not available 
Requirement sailfish-components-webview-qt5-popups not available

But a pass on validation in the SDK? I don’t really need it currently, so I’m rebuilding but???

Could you send me a direct message with the app name, submission date, etc. please? I don’t see any apps of yours that were rejected recently.

Heh, that’s because I removed the dependencies. But the message I pasted above was copied out of the Tidings upload dialog. It required me to remove the package. Upon which I rebuilt without popups.

The commit.

Thanks for reporting, and sorry for the inconvenience. This is now fixed and the -pickers and -popups packages are included in the server side configuration.

1 Like

Thank you very much!

1 Like

Are there some news about the improvement of stability of Sailfish WebView (and components) in the 4.5 update?

What kind of instability are you experiencing? Please create a bug report about it in the #bug-reports category.

After reading the changelog I’m wondering about the changes for the QML Sailfish WebView for apps. There where random crashes for Sailfish WebView in 4.4, e.g. with the jolla mail app. For 4.5 I need some time for testing. I hope no bug report is needed :slight_smile:

One thing to bear in mind is that instability with the mail app may not be directly caused by the WebView, even though it may feel like it.

For example, we had random crashes with the WebView when creating accounts that looked very much like a WebView problem. It turned out to be something entirely different (in case you’re curious, the fix is listed in the changelog as “[libjollasignonuiservice] Avoid accessing deleted query.”).

I’m not sure whether this is the case for the email app, but it’s possible, so just worth bearing in mind.

1 Like

I’m just doing the last of my updates and there are some issues which may need work in the html that’s loaded. The simple mahjong (aka ‘Green Mahjong’) that I package no longer loads in the new WebViews and it looks like I need to deal with that in the original javascript.

The biggest pain, sometimes one has to remove old

.cache/org/app/.mozilla and
.local/share/org/app/__PREFS_WRITTEN

files for the app to initialize properly (.mozzila prefs have changed but won’t be writter with that PREFS file).

It looks like this kind of thing causes the WebView to flip out trying to load a resource:

        function initRouter() {
            if (this.initpage)
                window.location.replace("#" + this.initpage());
            else
                loadDefaultPage();

        }

When testing my app Ielig:Web I have some crashes after

webView.url = "my url"

but is is to early for a bug report. Maybe there are to many pageStack.push(), pop() and append(). More tests needed here.

In rare cases I have this message but no real crash (can go back):

greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
EmbedLiteChromeListener: sending async message failed [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIEmbedAppService.sendAsyncMessage]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///usr/lib/mozembedlite/components/EmbedLiteChromeManager.js :: sendAsyncMessage :: line 62"  data: no]

Tested on XA2 with 4.5.0.18