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

Identifying MINIMUM dependencies ¶

In the interests of avoiding wasting electricity by unnecessarily rebuilding packages which were adequate, I have reviewed changes in newer versions of firefox. As noted below, I cannot keep up with BLFS-dev any more. My notes on what to look at (up to date for firefox-131) and my 'slimfox' script to reduce the diffs so that irrelevant items are not in the 'slim' diff are at ​https://www.linuxfromscratch.org/~ken/mozilla-notes/.

Dependencies for the 115esr series ¶

There will be no further firefox-115esr releases after 115.16.0esr. As with all graphical browsers, keeping up to date will reduce the attack surface. Therefore you should move to firefox-128.3.0esr or later as soon as possible.

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

If you are updating a very old system, and rust needs a newer LLVM, llvm-17.0.6 is good enough.

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-131 series ¶

cbindgen >= 0.26.0

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

nss >= 3.104.0

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 132.0beta ¶

Details may follow. At a mimimum, the nss version is always bumped for a new series, sp probably 3.105.0 for firefox-131beta.

Please be advised that I (ken) no-longer normally test this while EARLY_BETA_OR_EARLIER is defined, because of apparent opt-ins for various things. That define used to be unset in b9 but it is now unset in b7.

Similarly, I cannot keep up with the churn in BLFS-dev, so fixes to build either latest esr or latest stable or beta are outwith my abilities.

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