Firefox

Profiles

Firefox has a nasty habit of requiring a new profile every few releases. I say this is nasty because logins, current tabs, plugins (even if still supported) and perhaps bookmarks can be lost. In addition, it tends to name the profiles default, then default.default when it creates another. This can also apply when downgrading the version (e.g. going from 69.0 to 68.2.0esr). 73.0 required a new profile, that profile continues to work in 78.0

If you wish to use multiple profiles (or to be able to rename or delete old profiles), open firefox with 'firefox -P'.

You can also tell firefox to use a profile which it warns is old, either by invoking it from a term in xorg using 'MOZ_ALLOW_DOWNGRADE=1 firefox' or by invoking it as 'firefox --allow-downgrade'. The latter invocation has been troublesome in the past but appears to work since 68.2.0 and can be used from a desktop 'launcher'.

For 91.0esr, firefox seemed to want to create a new profile when coming from 78esr, but using 'firefox -P' allowed it to use the existing profile. If you have created redundant profiles, or wish to rename profiles, 'about:profiles' will open the profile manager to permit this.

When upgrading from firefox-91esr to 102esr the profile was automatically upgraded. However, if you have multiple systems on the same machine (esr in /usr, latest in /opt) which share /home (in my case, development and released systems), invoking firefox on another system after one system has been updated, even just starting the profile selector or running firefox --version, is enough to get the profile marked as trashed. Backups of ~/.mozilla are good :-) Related issues with upgrading the latest to 103.0 iff I used my (extra) desktop file, except I got 102 instead of 103, with the esr items. Starting from a term and specifying that PATH to the required firefox using -P allowed my to sort things out.

Which version should I use ?

In general, BLFS tries to always use latest releases. For firefox up to and including 69.0 the latest version was normally used. But in late 2019 mozilla decided to move to a more-frequent release schedule (eventually 4 weeks instead of 6 or 7 weeks).

Newer versions tended to need newer versions of rust, but this has cause problems with other packages which use rust. In particular, thunderbird releases are based on the firefox esr (extended support releases) code and tended to have code which did not build with the latest version of rust. Nowadays, seamonkey might also be in that situation, but is anyway currently unable to build with system python-3.11.

There are only a few packages in BLFS which use rust and the editors aim to ensure that all the versions in the book can be built with the same version of rust.

As a result, after firefox-69 the book moved to the esr versions of firefox which for 68esr was technically a downgrade (see details about profiles above), but contained all the relevant security fixes.

You should always use the latest release, either the latest esr or the latest mainline version (or the latest beta for bleeding edge). And you should remember to update your ca-certificates when building a new version of firefox.

Dependencies for the 115esr series

cbindgen >= 0.24.3

icu >= 73.1

The shipped libpng is now 1.6.39, using system libpng-1.6.40 with the apng patch works.

libvpx >= v1.13.0 (shipped version has various changes, seems to be ok with system libvpx-1.13.0).

libwebp : An upstream patch was cherry-picked for ff112 (and ff102.10.0) to fix builds with the shipped libwebp. For building with system libwebp use the patch which is in BLFS libwebp-1.3.0 r11.3-312 OR update to libwebp-1.3.1 which has now been released.

nss >= 3.90.0 (for 3.90 use the patch for haswell and earlier machines, fixed in 3.91)

nspr >= 4.35

rustc >= 1.66.0

If you need to build rustc-1.70.0, that requires LLVM >= 14. LLVM-16.0.5 builds ok with (at least) gcc-11.2.0 from BLFS-11.1.

The minimum version of node-js has now been updated to v12.22.1, that old out of support version is apparently still used on old debian which might be what some of the build-bots at mozilla use. You should use a supported version of node-js, updated as necessary to fix its vulnerabilities.

Dependencies for the latest release

This is an attempt to help people who want to keep using the latest upstream release, and will be updated from time to time. It is also a store for any changes which will need to be addressed when the book moves to the next ESR version.

Note that point releases of the current stable versions are not specifically monitored, if you use the current stable version you should check for updates and their release note and any security fixes.

Dependencies for 125.0 series (latest upstream stable)

Changed dependencies since 115.0:

cbindgen now needs to be >= 0.26.0.

libpng has been updated to 1.6.43 in the shipped version, using the same version for system apng is recommended.

The shipped libvpx is now 1.14.0, this is intended to be binary compatible with 1.13.1.

nss >= 3.99.

rust >= 1.74.0.

The workarounds needed to use LLVM-18 with firefox-115.8.0 and later are not needed with firefox-123.0 or later.

The fixes in the development book for python-3.12 needed in firefox-115.4.0esr and later were included in firefox-120.0. The fix to allow use of system icu-74 is still needed and unlikely to be applied upstream because of the experiments with icu4x.

Ptyhon-3.12 is not yet supported.

Mozilla are experimenting with bundling icu4x.​https://github.com/unicode-org/icu4x At the moment, using that bundled version would need adding 'ac_add_options --enable-icu4x' to the mozconfig, but I suspect it will eventually imply the end of using system icu4c.

There was a lot of change in the shipped ICU4X code between 117.0 and 118.0b1. For the moment, system icu remains available and gives a faster(+1.3 SBU using 8 jobs) and smaller build (icu4x adds 97 MB to the build directory and 17 MB to the install)- that was tested with rustc-1.71.1 and cbindgen-0.24.3 with firefox-118.

The release notes for 118 talk about translation on the local machine, AFAICS that requires building with WASM.

Sandboxing

From firefox-95 on, the build system wants to use "wasi-sysroot" to sandbox some of the shipped libraries (by converting to wasm and then back to sandboxed C). That will require, amongst other things, LLVM built for WebAssembly (that is default, but BLFS does not enable it), wasi-libc ​https://github.com/WebAssembly/wasi-libc, some other supporting packages, and using clang (we already do that) and probably lld (the llvm linker). If you want to do that, look at what Arch is doing. Please note that it looks as if static libz.a is needed to do that, and LFS deletes that.

For the moment, g++ can be used if you pass --without-wasm-sandboxed-libraries but the changes in gcc-12 mean that the book has moved to using clang++, still without wasm.

Dependencies for 126.0beta

As of 126.0b1 the versions of system dependencies are unchanged.

Please be advised that I no-longer normally test this while EARLY_BETA_OR_EARLIER is defined, because of apparent opt-ins for various things. That define is normally not present in beta9.

The early betas for 92.0 and 93.0 needed static libstdc++.a to link logalloc-replay (that specifies -static-libstdc++). In later betas that was not compiled. While using a static system lib (outside of rust) is annoying, the expected lifetime of a firefox beta is short and this requirement can be remembered if a vulnerability in libstdc++ is ever disclosed. I assume this requirement will continue for early betas (those where EARLY_BETA_OR_EARLIER is defined in build/defines.sh).