flypig.co.uk

In my previous job working for Jolla one of the projects I worked on was the browser upgrade. The Sailfish Browser uses Mozilla's Gecko Web engine — the same engine used in Firefox — but optimised for embedded devices. The browser is a key component on any consumer-oriented phone. It's likely one of the most used applications, and on a phone that doesn't have the same level of reach for application development as Android or iOS, it can be a critical way of accessing services that might otherwise need an app. On Sailfish OS the browser is really important and it was a genuine privilege to get to work on it.

To be effective the browser needs to be fast at rendering and compatible with the widest possible pool of websites. Basing the Sailfish Browser on the same engine as Firefox helps achieve both of these. Compatibility isn't perfect because of the crazy hoops websites will jump through to try to block anything even slightly non-standard, but it's as close as we can hope for.

But to retain this compatibility we also need to use an up-to-date version of the engine. That means keeping it updated to a recent release.

Beyond this it also needs a decent array of features, things that users have grown to expect such as password management, tab support, privacy features and a whole lot more. Providing these requires deep integration with the gecko engine, but most of them won't be fully implemented by the engine alone.

So maintaining a browser is a lot of work, and requires extended commitment.

During my time at Jolla we upgraded gecko first from ESR 60 to ESR 68, then from ESR 68 to ESR 78. Just to explain briefly, ESR stands for "Extended Support Release". These releases retain support for a longer period of time compared to the standard releases, which means that they get bug fixes but not new features. Adding new features also tends to add bugs and introduce regressions, so the idea is that the ESR releases will acquire fewer bugs and greater stability over time, compared to what you might expect when tracking the latest release.

ESR releases tend to be supported for at least a year. It would be great if the Sailfish Browser could be updated on every gecko release, but unfortunately this just isn't realistic. A good compromise is to aim to keep it up-to-date with at least the most recent stable ESR.

Since ESR 78 Mozilla has released ESR 91, ESR 102 and ESR 115 versions of Gecko. The last of these is still in development, so we'd really want the Sailfish Browser to be at 102 right now. So we're actually two ESR releases behind.

Upgrading gecko for Sailfish OS is a big job. Just checking the git history I can see that the upgrade from ESR 68 to ESR 78 took in the region of nine months work from a team of contributors. Like I said, it's a big job.

While I was at Jolla the browser team was headed up by Raine. Raine has a boatload of experience working with the gecko engine and was a superb team leader. Throughout my time working with him he went out of his way to share his knowledge of the browser and to encourage us to share ours with others. He was motivated to ensure we didn't get too reliant on any one developer. In my view, this is the mark of an excellent software dev lead, which he is. His view was that upgrading more than one ESR at a time was bound to fail: as a task it's just too complex. Nothing I've seen of gecko makes me doubt his assessment.

As such, the next step for the Sailfish Browser should be to update it from the current version to ESR 91. After that we can think about moving it to ESR 102 which is where we'd like it ideally to be right now.

Patches

You might reasonably wonder why building gecko for Sailfish OS is quite such a big job. After all, gecko runs on Linux and Sailfish OS is really just a Linux variant. Shouldn't it just compile straight away?

That's true up to a point, but there are three significant catches with this.

First, gecko has quite a lot of toolkit-specific code, whether that be for Gtk, Windows, Cairo or Android. Historically there was also the EmbedLite API that allowed the renderer to be embedded in a native user interface, including using Qt in the form of QtMozEmbed. The Sailfish Browser is built on this. Sadly Gecko dropped official support for this and Jolla has been the de fecto maintainer of the code since 2015 or thereabouts. Maintaining this involves keeping the Sailfish OS changes in line with upstream gecko changes, which is a big chunk of the work required when updating to a new version for Sailfish OS.

Second, Gecko uses its own build scaffolding written in Python called Mach. Different parts of Gecko use different languages and tooling, mostly C++, Rust and JavaScript using gcc, clang and rustc. If you're a Sailfish OS developer you'll know the standard Sailfish OS development toolkit is a cross-platform SDK based on scratchbox2. Getting the two to work together can be intricate. For example, some Rust components form part of the build process while others get linked into the final executable. The former must be built for the host platform whilst the latter must be built for the target platform. Getting the gecko build process and sb2 to agree on which is which can be troublesome. On top of all that, Gecko has a bunch of build and runtime dependencies which need updating each release as well.

Third, there are a large number of Sailfish-specific integrations that go beyond the rendering engine. For example, integrations that allow searching within pages, saving pages to PDF, playing audio, rendering video, capturing audio and video, storing history, bookmarks and passwords. The browser is more than just the rendering engine and front-end functionality invariably has deep links into the backend gecko engine.

So, to cut a long story short, just getting an updated gecko to compile requires time and effort. Another piece of wisdom that Raine taught me is that the first task of upgrading the engine should always be to get it to compile. Once it's compiling, getting it to actually run on a phone, patching all of the regressions and fixing up all the integrations can follow. But without a compiling build there's no point in spending time on these other parts.

My plan is to follow his advice. I'm therefore going for a three-stage process with this upgrade:

1. Apply a minimal set of changes and patches to get ESR 91 to build using the Sailfish SDK.
2. Apply any remaining patches where possible and other changes to get it to run and render.
3. Handle the Sailfish OS specific integrations.

The first stage will be a laborious step-by-step process that involves attempting a build, hitting a build error, fixing the build error (without testing how it affects the runtime execution). Rinse and repeat until the build fully succeeds. Just the process of running the build can take several hours (between five to eight on my development machine) so it's a slow process, even with incremental builds.

So this could take some time, but my plan is to write about each of the steps as I go through them.

These might not make for the most fascinating posts, but they'll serve as a useful personal record of my progress and maybe they'll be of interest to others too.

So that's the scene set. In the next post I'll start to do some actual real work, test out the build and see where that gets us. I'll aim to write as often as possible and if you're following along I hope you find it interesting.

One last thing: the Sailfish OS community is one of the best. I know there will be Sailfish OS users and developers itching to help and get this project across the line. And if this is going to work, I'll need that help. Once there's a working build that others can try out, it'll become a whole lot easier to cooperate on the code and test things out. If this is something you're interested in contributing to, please watch this space.

To read all of my posts on this topic, please see my Gecko-dev Diary page.