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).

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 can be used from a desktop 'launcher' - but using it might cause problems. In general, creation of new profiles during an upgrade is automatic, you might give problems if you build a newer version and then find something has broken since the previous version and decide to revert.

If you have created redundant profiles, or wish to rename profiles, 'about:profiles' will open the profile manager to permit this.

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, ican be enough to get the profile marked as trashed. Backups of ~/.mozilla are good :-)

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 caused 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.

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

You should aim to move to the firefox-128esr series before the 115esr series goes out of support in September 2024. If you are on a current BLFS development system with ffmpeg-7 or greater you should move to 128esr ASAP because mp4 playback in 115esr was broken with system ffmpeg-7.

cbindgen >= 0.24.3

icu >= 73.1

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

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

libwebp : An upstream patch was cherry-picked for ff112 (and ff102.10.0) to fix builds with the shipped libwebp.Use system libwebp-1.4.0 nss >= 3.90.0 (for 3.90 use the patch for haswell and earlier machines, fixed in 3.91). Using current nss (and current nspr if that needs to be updated) is recommended.

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 128.0esr series (latest extended support series)

With 128.0esr the only differences from 128.0 are that it reports its version as 128.0esr, and there are changes in some of the json files (reason unknown). Therefore, the dependencies are:

cbindgen >= 0.26.0

libpng has been updated to 1.6.43, using same system version is recommended

shipped libvpx is now 1.14.0, system 1.13 or 1.14.1 should be compatible.

nss >= 3.101 : current nss (and the required nspr version, although that has been held at 4.35 for a long time) is recommended.

rust >= 1.76.0, the workaround for rustc => 1.78.0 to remove code only useful for ARM which fails to compile is probably still needed (removing does no harm).

The shipped icu remains at version 73.1 and will probably not change and eventually be replaced by shipped icu4x which gives no obvious benefits here and makes the build a little bigger and longer. To use system icu-74 or later, the fixes in the development book are still required.

You should continue to update node.js to supported versions whenever they make a security release.

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.

Firefox-128 series

cbindgen >= 0.26.0

libpng has been updated to 1.6.43, using same system version is recommended

shipped libvpx is now 1.14.0, system 1.13 or 1.14.1 should be compatible.

nss >= 3.101

rust >= 1.76.0, the workaround for rustc => 1.78.0 to remove code only useful for ARM which fails to compile is probably still needed (removing does no harm).

The shipped icu remains at version 73.1 and will probably not change and eventually be replaced by shipped icu4x which gives no obvious benefits here and makes the build a little bigger and longer. To use system icu-74 or later, the fixes in the development book are still required. Using shipped icu4x would require adding 'ac_add_options --enable-icu4x' to the mozconfig.

The release notes for 118 talked 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 129.0beta

To Be Advised.

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 but in firefox-128 it was unset at or before 128.0b7.

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).