flypig.co.uk

Yesterday was a good day given Thigg's graphical intervention. I also tried installing the newly generated gecko 91.9.1 rpm packages on my phone, with predictably unsuccessful results. Installation was blocked because there are at least a couple of packages (QtMozEmbed and the browser booster) which depend on it, and they insisted on linking against only the previous version of the library.

This isn't a disaster, it just means I have to rebuild them against the new library. But unfortunately this isn't just as simple as performing a rebuild because the libxul API has changed.

None of these API changes are a particular surprise: I recognise them as changes that I made to various headers from the library. But I will need to update QtMozEmbed to use them properly.

One of the nice things about this piece of work is that at least QtMozEmbed compiles pretty swiftly. That'll make the development process much easier than it is for gecko. Frankly, it's a breath of fresh air.

The first issue is that the qmozcontext.cpp file is trying to import mozilla/embedlite/EmbedInitGlue.h which apparently no longer exists. First thing to check is whether or not that's actually true.

And it is true: it's not there. But interestingly it's not there in ESR 78 either. Or rather, it is there, but it's not in the git tree. That's because it's been generated by a patch; a patch that I've not applied: patch 0018 "Introduce EmbedInitGlue to the mozglue".

I'll try to introduce it now.

$ git am --3way ../rpm/0019-sailfishos-mozglue-Introduce-EmbedInitGlue-to-the-mo.patch
Applying: Introduce EmbedInitGlue to the mozglue. JB#50788
Using index info to reconstruct a base tree...
M       mozglue/moz.build
Falling back to patching base and 3-way merge...
Auto-merging mozglue/moz.build
CONFLICT (content): Merge conflict in mozglue/moz.build
error: Failed to merge in the changes.
Patch failed at 0001 Introduce EmbedInitGlue to the mozglue. JB#50788
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

It's not quite a smooth application, but with some manual tinkering the conflict is turns out to be pretty straightforward to resolve. The thing to do now is create a new set of gecko rpm packages. But there are more errors in QtMozEmbed that it's worth trying to sort out first. It doesn't look like all of them are caused by the lack of this header file.

There's an error about ArrayLength() not being defined. This function (or maybe macro?.. no, it's a function) hasn't been removed: it's widely used in the gecko code. So it's probably just a case of a header file not making it into the QtMozEmbed code.

Just to complicate things, gecko has it defined in three distinct header files, so it's not clear which one we need to use.

I've had a look at a couple of gecko source files and the common include seems to be mozilla/ArrayUtils.h so I've decided to go for that one.

Next up we have this:

qopenglwebpage.cpp: In destructor ‘virtual QOpenGLWebPage::~QOpenGLWebPage()’:
qopenglwebpage.cpp:76:36: error: no matching function for call to
  ‘mozilla::embedlite::EmbedLiteView::SetIsActive(bool)’
         d->mView->SetIsActive(false);
                                    ^

You may recall that back on Day 30 we had to change the signature for SetIsActive(). Here's the relevant commit log message:

commit 96ae695458d3beb6ca4614f07e1915eff3577fe3
Author: Henri Sivonen 
Date:   Mon Nov 16 19:16:20 2020 +0000

    Bug 1618386 - Add action ids to filter out stale active browsing context updates. r=nika
    
    Differential Revision: https://phabricator.services.mozilla.com/D94969

This was the active ingredient for that commit as far as the current error is concerned:

-  virtual void SetIsActive(bool);
+  virtual void SetIsActive(bool, uint64_t aActionId);

So to get the QtMozEmbed code to compile we have to add an appropriate uint64_t aActionId to the SetIsActive() calls. I'm going to send in the value returned by nsFocusManager::GenerateFocusActionId() here, since this is what code elsewhere in gecko seems to be using.

Next we have this:

SailfishOS-devel-aarch64.temp/usr/include/xulrunner-qt5-91.9.1/mozilla/embedlite/
  EmbedLiteView.h:83:16: note:   candidate expects 2 arguments, 1 provided
qmozview_p.cpp: In member function ‘void QMozViewPrivate::goBack()’:
qmozview_p.cpp:444:19: error: no matching function for call to
  ‘mozilla::embedlite::EmbedLiteView::GoBack()’
     mView->GoBack();
                   ^

Plus a similar error for GoForward(). You might recall that we also changed these back on Day 30 to have an extra couple of parameters, bool aRequireUserInteraction and bool aUserActivation.

Ultimately we may want to expose these parameters from QtMozEmbed, but for the time being I've set both parameters to true in the two places these were used.

In theory that should cover all of the QtMozEmbed errors, but we can't find out now until the gecko build has finished. Then we can install the new gecko packages in the SDK to build QtMozEmbed against to see what happens.

So that's it for today. More tomorrow!

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