flypig.co.uk

I've been working through a singular bug stack for so long now that it feels strange to have a completely open ended set of possibilities for which direction to go next. We had a small diversion yesterday into creating random grids of avatars but before that were focused for a while on the task of getting DuckDuckGo working. Today I have to make some new decisions about where to go next.

There are two things I'd really like to look into. While working on the browser over the last weeks it's been stable enough to use pretty successfully as a browser. But occasionally the renderer crashes out completely, pulling the browser down, for no obvious reason. It's sporadic enough that there's no obvious cause. But if I could get a backtrace from the crash that might be enough to start looking in to it.

So my first option is looking in to these sporadic crashes. They're not nice for users and might signify a deeper issue.

The second option is fixing the webview rendering pipeline. That needs a little explanation. On Sailfish OS the browser is used in one of two ways, either as a web browser, or as a webview embedded in some other application.

The best example of this is the email client which uses the webview to render messages. These often contain HTML, so it makes perfect sense to use a good embedded browser rending engine for them.

So these are two different use-cases. But they also happen to have two different rendering pipelines. Currently the browser pipeline works nicely, but the webview pipeline is broken. I'd really like to fix it.

I've decided to go with the native rendering pipeline task first (issue 1043 on GitHub). It's clearly defined, but also potentially a big job, so needs some attention. But if I continue to see browser crashes I may switch focus to those instead.

For the native rendering pipeline the first step is straightforward: install a webview project on my phone. There are plenty out there, but I also have several basic examples already written in the "projects" folder on my laptop, and which I should be able to just build and install on my phone for testing.

Digging through projects I find one called "harbour-webview-example" (sounds promising) with the following as the main page of the app:

import QtQuick 2.0
import Sailfish.Silica 1.0
import Sailfish.WebView 1.0
import Sailfish.WebEngine 1.0
import uk.co.flypig.webview 1.0

Page {
    allowedOrientations: Orientation.All

    WebView {
        anchors.fill: parent
        active: true
        url: "http://www.sailfishos.org"
        onLinkClicked: {
          WebEngine.notifyObservers("exampleTopic", url)
        }
    }
}

Straightforward. But containing a webview. Attempting to run it, the results sadly aren't good:

$ harbour-webview
[D] unknown:0 - QML debugging is enabled. Only use this in a safe environment.
[...]
JSComp: UserAgentOverrideHelper.js loaded
UserAgentOverrideHelper app-startup
CONSOLE message:
[JavaScript Error: "Unexpected event profile-after-change"
    {file: "resource://gre/modules/URLQueryStrippingListService.jsm" line: 228}]
observe@resource://gre/modules/URLQueryStrippingListService.jsm:228:12

Created LOG for EmbedPrefs
Content JS: resource://gre/modules/SearchSettings.jsm, function: get, message:
    [JavaScript Warning: "get: No settings file exists, new profile?
    NotFoundError: Could not open the file at
    .cache/harbour-webview/harbour-webview/.mozilla/search.json.mozlz4"]
Created LOG for EmbedLiteLayerManager
Segmentation fault

There are a couple of JavaScript errors (may or may not be related) and a crash (definitely relevant). Let's see if we can get a backtrace from the crash:

$ gdb harbour-webview 
GNU gdb (GDB) Mer (8.2.1+git9)
Copyright (C) 2018 Free Software Foundation, Inc.
[...]
Thread 7 "GeckoWorkerThre" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 12581]
0x0000007ff367c0a8 in mozilla::embedlite::PuppetWidgetBase::Invalidate
    (this=0x7fc4dac130, aRect=...)
    at mobile/sailfishos/embedshared/PuppetWidgetBase.cpp:274
274         MOZ_CRASH("Unexpected layer manager type");
(gdb) bt
#0  0x0000007ff367c0a8 in mozilla::embedlite::PuppetWidgetBase::Invalidate
    (this=0x7fc4dac130, aRect=...)
    at mobile/sailfishos/embedshared/PuppetWidgetBase.cpp:274
#1  0x0000007ff368093c in mozilla::embedlite::PuppetWidgetBase::UpdateBounds
    (this=0x7fc4dac130, aRepaint=aRepaint@entry=true)
    at mobile/sailfishos/embedshared/PuppetWidgetBase.cpp:395
#2  0x0000007ff3689b28 in mozilla::embedlite::EmbedLiteWindowChild::CreateWidget
    (this=0x7fc4d626d0)
    at xpcom/base/nsCOMPtr.h:851
#3  0x0000007ff367a094 in mozilla::detail::RunnableMethodArguments<>::applyImpl
    <mozilla::embedlite::EmbedLiteWindowChild, void
    (mozilla::embedlite::EmbedLiteWindowChild::*)()>
    (mozilla::embedlite::EmbedLiteWindowChild*, void
    (mozilla::embedlite::EmbedLiteWindowChild::*)(), mozilla::Tuple<>&,
    std::integer_sequence<unsigned long>) (args=..., m=<optimized out>,
    o=<optimized out>)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsThreadUtils.h:1151
[...]
#28 0x0000007ff6a0489c in ?? () from /lib64/libc.so.6
(gdb) 

That's definitely something to go on. But unfortunately I'm tight for time today, so digging in to this backtrace will have to wait until tomorrow.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.