flypig.co.uk

It's most definitely autumn now. The trees and bushes outside are still green, but covered with bright red berries and fruit. The birds are making the most almighty racket in the trees, preparing for their annual migration. I do love this time of year. The nights are longer and darker and very soon the leaves will also start their migration through fiery colours and then from branch to floor.

When I'm not staring out of the window contemplating autumn you'll find me staring at my laptop screen, unaffected by the changing seasons. It looks very much as it did when I started this process. But things have been progressing even if this isn't reflected in any changes onscreen.

If you've been following along you'll know that yesterday I got to the point where ESR 91 was running on my phone. I appreciate all your comments on the forum including the suggestions for how to work around the C++17 issue with the MOC. I plan to try them out in due course.

The fact the executable run is a pretty exciting step, but also comes with major caveats. It was running without crashing, but it wasn't rendering anything. It could only be coaxed into running beyond the first moments of execution with some nasty symlink hacks so it could find the library and using some pretty intrusive debugger surgery.

That leaves us with two immediate issues to address. The first is ensuring it looks in the correct folder for the libraries so it can actually run. The second is ensuring it doesn't immediately crash by forcing the WEBRENDER_SOFTWARE graphics variable to false (which is what the gdb-hackery was all about).

I'm going to focus on the second first, because it's the more interesting.

Some notes worth recording are the fact that the enum list of variable names can be found in the gfxFeature.h header file. Gecko has this wonderful pre-processor macro approach of dealing with setting enums and names. It's obfuscatory, but I like it.

Then the work of collating and managing these configuration variables happens in gfxConfig.h. Finally the code that needs to use the value (which is the point where the debugger currently comes in useful) is in the InitWebRenderConfig() method which can be found in the gfxPlatform.cpp file.

While combing through the code this morning before work I found this method inside gfxFeature.cpp that looks like it's going to read the default state of the variable from a settings file.

void FeatureState::SetDefaultFromPref(const char* aPrefName, bool aIsEnablePref,
                                      bool aDefaultValue,
                                      Maybe aUserValue) {
  bool baseValue =
      Preferences::GetBool(aPrefName, aDefaultValue, PrefValueKind::Default);
  SetDefault(baseValue == aIsEnablePref, FeatureStatus::Disabled,
             "Disabled by default");

  if (aUserValue) {
    if (*aUserValue == aIsEnablePref) {
      nsCString message("Enabled via ");
      message.AppendASCII(aPrefName);
      UserEnable(message.get());
    } else {
      nsCString message("Disabled via ");
      message.AppendASCII(aPrefName);
      UserDisable(message.get(), "FEATURE_FAILURE_PREF_OFF"_ns);
    }
  }
}

Following this lead takes me to gfxConfigManager::Init() where we can see that it's possible to forcefully disable Web Render in full using an environment variable. Here's the line in this method:

  mWrEnvForceDisabled = gfxPlatform::WebRenderEnvvarDisabled();

And this is what it's calling (this can be found in gfxPlatform.cpp:

/*static*/
bool gfxPlatform::WebRenderEnvvarDisabled() {
  const char* env = PR_GetEnv("MOZ_WEBRENDER");
  return (env && *env == '0');
}

And this environment variable does seem to work in practice. If I run the browser like this, it will execute and stay executing:

MOZ_WEBRENDER=0 sailfish-browser

That's good, but I want a permanent solution based on a preference value that I can set. Further up in the same Init() method is this line which looks like it should have a similar effect: mWrForceDisabled = StaticPrefs::gfx_webrender_force_disabled_AtStartup(); Let's follow this path a bit too. This is defined in StaticprefList_gfx.h and associated with the gfx.webrender.force-disabled preference. If we can set that in a configuration file, we might be done.

There are a bunch of default preference that can be found in ~/.local/share/org.sailfishos/browser/.mozilla/prefs.js and if I add the preference there like this:

user_pref("gfx.webrender.force-disabled", true);

Then that also allows the browser to run. But as it warns at the top of this file, this isn't the place to put it:

// Mozilla User Preferences

// DO NOT EDIT THIS FILE.
//
// If you make changes to this file while the application is running,
// the changes will be overwritten when the application exits.
//
// To change a preference value, you can either:
// - modify it via the UI (e.g. via about:config in the browser); or
// - set it within a user.js file in your profile.

So we really want to put it elsewhere. The correct place seems to be in sailfish-browser. Either in the data/prefs.js file, or set in code in the DeclarativeWebUtils::setRenderingPreferences() method. I think I'm actually going to go for both of those for good measure.

Having made those changes I've built myself some fresh-looking sailfish-browser rpms. The sailfish-browser package essentially provides the user interface to the browser engine. It's not as big as Gecko, but it's still a large piece of software. It takes a good five minutes to build from scratch. I'll need to transfer the new packages over to my phone to test them out. The gecko rpms that were building overnight have also completed, so I'll need to install those as well.

$ cd sailfish-browser
$ sfdk -c snapshot=temp -c no-pull-build-requires build -d -p
$ scp sailfish-browser-*.prm defaultuser@10.0.0.116:~/Documents/Development/gecko/
$ ssh defaultuser@10.0.0.116
$ cd ~/.local/share/org.sailfishos/browser
$ mv .mozilla .mozilla.bak
$ cd ~/Documents/Development/gecko/
$ devel-su rpm -U sailfish-browser-2.*.rpm sailfish-browser-settings-2.*.rpm
$ sailfish-browser

After this change the browser now starts up and continues running without errors. Astonishingly (to me) it even shuts down without errors as well. Of course it's still not doing any rendering.

Before moving on to the rendering we need to get it finding the correct location of the library. In other words, it needs to look in /usr/lib64/xulrunner-qt5-91.9.1/ rather than /usr/lib64/xulrunner-qt5-78.15.1/. This was an issue we were seeing yesterday.

One possibility is that rebuilding sailfish-browser against the new gecko library may have already fixed the issue. Worth checking like this:

$ devel-su rm /usr/lib64/xulrunner-qt5-78.15.1
$ sailfish-browser

The results are good! The browser now picks up libxul.so from the intended location in /usr/lib64/xulrunner-qt5-91.9.1/.

That resolves all of the immediate non-rendering-related problems. But I do still have one further task to do before moving on to this rendering issue. It's that pesky untechnical-debt again.

In particular, I need to transfer all of the issues that have been collecting during these last fifty one days and register them on the sailfish-browser bug tracker. But that's going to have to wait until tomorrow.

If you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.