flypig.co.uk

As I write this it's the first day of Meteorological Autumn. It still feels very much like summer though (maybe because we won't reach Astronomical Autumn until later in the month). The sun is shining, there's a light breeze, crickets are chirping and there's a generally relaxed atmosphere in the air. But it's the changes in season that are always the most exciting time of year for me. I've enjoyed the summer, but I'm now looking forward to autumn and all of its mellow fruitfulness. Just thinking about it energises me.

But it also represents a shift in gear for this gecko diary as well. I'm hoping to get my pull requests submitted today. That doesn't mean the work is over, but it does mean that it's reached a stage where I feel it can be built upon (by both me and others). Moreover, as I mentioned previously I'll be taking a break this week while I'm attending a conference. So this will be my last diary entry until next weekend.

But that still means there's work to do today and I got up early this morning to check the build I started last night. And...? sadly it didn't complete. Most of the six patches I added last night seem to have built okay, but the startUpCache patch has caused errors. And a lot of errors at that. Although there are pages and pages of errors they all seem to be of one of two flavours.

First there are namespace errors

364:14.24 ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsILoadInfo.h: In member 
    function ‘bool nsILoadInfo::
    GetAllowListFutureDocumentsCreatedFromThisRedirectChain()’:
364:14.24 ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsILoadInfo.h:849:5: 
    error: reference to ‘mozilla’ is ambiguous
364:14.24   849 |     mozilla::DebugOnly<nsresult> rv = 
364:14.24   849 |     mozilla::DebugOnly rv = GetAllowListFutureDocumentsCreatedFromThisRedirectChain(&result);
364:14.24       |     ^~~~~~~

Next there are undefined type errors (in this case nsresult):

364:14.30 ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsILoadInfo.h:962:32: 
    error: expected primary-expression before ‘>’ token
364:14.30   962 |     mozilla::DebugOnly rv = GetIsMediaRequest(&result);
364:14.31       |                                ^

And then there are yet more undefined type errors like this one:

364:14.36 ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/Services.h:480:46:
     error: ‘XPCOMService_GetHistory’ was not declared in this scope; did you 
    mean ‘XPCOMService_GetGfxInfo’?
364:14.36   480 |   return already_AddRefed(XPCOMService_GetHistory());
364:14.36       |                                              ^~~~~~~~~~~~~~~~~~~~~~~
364:14.36       |                                              XPCOMService_GetGfxInfo

There are so many errors, but I'm hoping that it's a cascade: a single error that's triggering a whole cascade of follow-on errors, rather than a huge collection of unrelated errors. Time to dig in and find out.

If I compare the code from ESR 78 it looks pretty similar, but I am a little surprised to see that the newly added Logging.h include is placed inside the namespace qualifiers:

using namespace mozilla::Compression;

namespace mozilla {
namespace scache {

#include "mozilla/Logging.h"

Although that does tally with the changes to the ESR 78 code, it doesn't match with the other ESR 91 files the Logging.h header is being included in, such as the EmbedLite code and elsewhere, so I'm going to move it out of the namespace and try again.

This gives much better results: the majority of the errors are now gone and I'm just left with a couple of errors related to use of NS_LITERAL_STRING() and NS_LITERAL_CSTRING(). This has been a recurrent issue throughout this process since the gecko code now requires use of an _ns string suffix rather than one of the previous NS_LITERAL_STRING() macros.

Having replaced the two string literals with the annotations the code now compiles without error. But it means I have to do a complete build again, which means I have to regenerate the startupCache patch again. The commits have changed because the patch descriptions have changed as a result of being applied by the build process, but other than this I can use the same command to generate the patches as before:

$ git format-patch --start-number 79 -o ../rpm -N --no-signature --zero-commit 
    24f9ec2df3d3

The great news is that although this generates six patches, only the startUpCache patch is registering any changes, the others are all identical to the previous versions. This is a really good sign and exactly what I was hoping for.

So I've updated the patches, added the changes to the commits, cleaned the entire source tree of cruft and now it's time for another full rebuild.

I want at least one full rebuild to go through without errors before I create this mythical pull request I've been going on about. It's frankly turning out to be a little more laborious to get it to happen than I was expecting. But it'll get there.

[...]

Now finally after a full day of compilation, the final full build has completed. I've copied over and installed the packages and a quick check suggests things are working as expected. The pages are returning correctly as mobile pages. The email app doesn't crash when you switch back from the homescreen. The WebView seems to be working correctly.

The browser does still segfault on exit and, after a discussion with Frajo, it's possible that this could be fixable. But this isn't a new issue and while it'd be great to have it fixed, it could take a while to figure out. So that's going to have to be something for the future.

The task now, finally, is to submit the pull request. In fact, not just one pull request, but all five of them for the various packages that have needed changes needed for supporting the new engine. After a bit of playing around on GitHub, here they are:

1. https://github.com/sailfishos/gecko-dev/pull/162
2. https://github.com/sailfishos/qtmozembed/pull/49
3. https://github.com/sailfishos/sailfish-browser/pull/1074
4. https://github.com/sailfishos/embedlite-components/pull/100
5. https://github.com/sailfishos/sailfish-components-webview/pull/169

It really feels good to get those submitted. This is by no means the end of the process of course. There are at least four more tasks:

1. Respond to the comments on the pull requests so they can be merged in. There are already some comments I need to address. Until they're merged in, they could still change a lot and ultimately, it's Jolla that has to decide whether or not to accept them. So they have to fulfil Jolla's requirements.
2. Fix all the issues that have already come up in testing of the browser. It looks like many of these may be addressed by the user agent fix and the libhybris changes, but there are others. And I'm sure there will be many more besides.
3. Fix the segfault on browser shutdown. This isn't new, but with the latest libhybris changes getting a clean shutdown feels closer than ever. It'd be so great if that could be achieved so it's worth spending a bit of time on it.
4. Get the browser working on native devices. An important fix, mustn't forget this!

All of these are important steps. But right now my main objective is to take a short break. As I mentioned previously I'm attending RSECon24 this week and that'll leave me very little time to work on the gecko code anyway. But to be honest, I think I need some time to decompress; it'll do me good to think about something else for a change.

I'll return to this next weekend and I'll continue with fresh diary entries then. But right now, I plan to spend a bit of time breathing in and enjoying the fresh autumnal air.

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