flypig.co.uk

Before I continue my investigation of the changes needed to get WebRTC integrated back into the browser, I want to first take stock. What's the current situation with the browser; what still needs to be done?

Well, the browser is now quite usable in my experience. There are some glitches, such as sporadic failures in the dark mode detection. But I wouldn't count that as critical failures. I've not really driven it hard (meaning, visited a large number of sites on the Web) but I've not generally experienced problems on the sites I've visited.

I've not been able to yet test the WebView running in the email client, but it works fine in the Settings app, so I expect it to work similarly well with the email app.

With these working correctly, it does feel like now would be a good time to roll out packages for others to try and lodge issues against. For users that have a second phone, or who are really willing to live on the cutting edge, I don't think it will be an unusable experience.

Nevertheless, it's also worth highlighting that I've not installed ESR 91 on my daily device. That's mostly just laziness on my part. I'm not sure I'd find it problematic if I did.

WebRTC and multimedia playback are the two obvious areas that need attention. Video works, but I'm not sure how it's happening or what backend it's using. Video playback isn't my area of expertise so I'm hoping Jolla will ultimately be able to help with this part.

There are some tidying up jobs to be done as well. Most notably I have to corral all of the commits I've made to the FIREFOX_ESR_91_9_X_RELBRANCH_patches branch into actual patches. I'm expecting this to be quite a bit of work; work that will require care and attention, but hopefully not too much thought.

So that's where things are at. Right now then, it's back to WebRTC so that I can cross the largest remaining item off this list. The ESR 78 WebRTC patches were developed by Denis Grigorev (d-grigorev), who I had the privilege of working with while I was at Jolla. Denis is a fantastic developer and did amazing work with these patches and I wouldn't want to have to replicate all of that from scratch. Frankly I'm not sure I could. My hope therefore is that I'll be able to apply the patches without too much drama.

As we saw yesterday there are five sequentially numbered patches that must be applied in order from 77 to 81 inclusive. Starting with the first patch, attempting to apply it gives disastrous results. None of the hunks apply successfully.

Checking the details of the patch it quickly becomes clear why: none of the files listed in the patch exist in the source tree any more. Or at least, they're not where they're supposed to be.

But checking the log for one of the missing files shows that it's been moved rather than removed:

$ git log -1 -- media/webrtc/trunk/webrtc/BUILD.gn
commit 9f1d2b5af54877aacf06605681a5b313c0441c51
Author: Dan Minor <dminor@mozilla.com>
Date:   Thu Sep 24 18:28:41 2020 +0000

    Bug 1665166 - Move media/webrtc/trunk/* to third-party/libwebrtc; r=ng
    
    Differential Revision: https://phabricator.services.mozilla.com/D91317

After a bit of experimentation I soon discover the description for this commit isn't quite correct. The file has actually been moved to third_party/libwebrtc (with an underscore rather than a hyphen). But having made this adjustment it appears that all of the relevant files have been moved there which, if correct, is going to make things much easier.

Looking through the patches I can see that the same issue is going to arise for patch 81. A quick bit of search-and-replace should fix this for both of them:

$ sed -i -e "s/media\/webrtc\/trunk\//third_party\/libwebrtc\//g" 
    0077-*.patch
$ sed -i -e "s/media\/webrtc\/trunk\//third_party\/libwebrtc\//g" 
    0081-*.patch

Now when I attempt to apply the first of these patches I get much better results:

$ git am ../rpm/0077-sailfishos-webrtc-Adapt-build-configuration-for-Sail.patch
Applying: Adapt build configuration for SailfishOS. JB#53756

Great! So that's patch 77 dealt with. Patch 78 is going to be a bit trickier, because this is the patch that applies the changes following the regeneration of the build process.

As we saw yesterday, there is in theory a simple command for regenerating the build configuration:

./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/webrtc.json

Checking the patch, we can see that the following files are the ones that need to be regenerated:

 .../gn-configs/arm64_False_arm64_linux.json   |  5874 +-------
 .../gn-configs/arm_False_arm_linux.json       |  6114 +--------
 .../gn-configs/x86_False_x86_linux.json       | 11339 ++++++++++++++++

I run the mach command inside the build engine like this:

$ source `pwd`/obj-build-mer-qt-xr/rpm-shared.env
$ cd gecko-dev/
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/arm64_False_arm64_linux.json
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/arm_False_arm_linux.json
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/x86_False_x86_linux.json

This all executes without incident, but in practice it doesn't have any effect. The build scripts are identical to what they were before: git status shows that nothing has changed. Could that be because the WebRTC is still disabled in our build configuration?

Looking back through my diary records I quickly find the option that's supposed to control this; we talked about it all the way back on Day 38. Here's the change that I committed back then:

$ git log -1 embedding/embedlite/config/mozconfig.merqtxulrunner
commit 577ff63ae39d49c83bab7fca86f2e1d32053d167
Author: David Llewellyn-Jones <david@flypig.co.uk>
Date:   Thu Sep 21 08:43:12 2023 +0100

    Disable WebRTC
    
    The WebRTC patches are large and tricky to apply. This change disables
    building of the WebRTC portions of the code so that reapplying the
    patches can be tackled later.
$ git diff 577ff63ae~ 577ff63ae
diff --git a/embedding/embedlite/config/mozconfig.merqtxulrunner b/embedding/
    embedlite/config/mozconfig.merqtxulrunner
index 2593d32fd5a9..bec8b01bb07b 100644
--- a/embedding/embedlite/config/mozconfig.merqtxulrunner
+++ b/embedding/embedlite/config/mozconfig.merqtxulrunner
@@ -46,7 +46,7 @@ ac_add_options --with-app-name=xulrunner-qt5
 # ac_add_options --enable-warnings-as-errors
 
 # disabling for now, since the build fails...
-ac_add_options --enable-webrtc
+ac_add_options --disable-webrtc
 ac_add_options --enable-profiling
 ac_add_options --disable-dbus
 ac_add_options --disable-necko-wifi

If I restored this so that the option is set to "enable-webrtc" rather than "disable-webrtc" then maybe I'll get better results? Let's see. In order for this change to work it'll need to be propagated through the build system, which means cleaning everything out and starting the build completely from scratch. So that's what I've done:

git clean -xdf
cd gecko-dev
git clean -xdf
cd ..
sfdk build -d -p --with git_workaround
[...]

I've set this running but I'm not exactly sure what to expect. My expectation was that the build would fail soon after the new build configuration had been generated, but after more than a quarter of an hour the build is still happily chugging away. It's also possible that it'll all just rebuild fine. That would be more unexpected, but you never know. Either way, it looks like it's not going to be the fast failure I thought it would be, so I'll need to leave the build running, probably overnight. We'll come back to this tomorrow to see how it's got on.

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