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 102esr series

cbindgen needs to be >= 0.23

icu needs to be >= 71.1

Firefox continues to test for node.js >= v10.23.1 which has not been maintained for a long time. If you have updated node.js to fix each reported vulnerability you should be OK. If not, update to the current version.

libvpx should be >= v1.11.0.

nspr needs to be >= 4.34

nss needs to be >= 3.79.4

rustc needs to be >= 1.59.0

The environment variable MACH_USE_SYSTEM_PYTHON has been deprecated since firefox-100.0, replace it by MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system.

See below re 'sandboxing' for how to disable wasi-sysroot, or where to look if you wish to use it.

New Themes (Tools -> Add-Ons and Themes) can make it easier to see which tab is active.

With the introduction of python-3.11, the build has changed its use of an environment variable, and now uses

export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=none

to work around situations where the versions of modules pulled in for firefox are regarded by one of its scripts as being incompatible with other modules such as sphinx.

With firefox-102.8.0 the python code has been fixed for python-3.11, seds are no-longer required.

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.

It looks as if firefox-103 updated the profile. Similarly, 108.0 seems to have updated the profile, but now it warns if trying to start with an older profile (shared /home across multiple BLFS builds) and lets you quit.

Dependencies for 113.0 series (latest upstream stable)

No changes in dependencies since 112.0, so still:

cbindgen >= 0.24.3 and therefore the sed needed for 102 is not wanted.

icu >= 72.1 (113.0 builds ok with ucu 73.1)

The shipped libpng has now been updated to 1.6.39, using the same version for system libpng is recommended.

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.

nss >= 3.89

nspr >= 4.35

rustc >= 1.65.0

The minimum version of node-js has now been updated to v12.22.1, unfortunately that fell out of support in April of this year, v14, v16 and v18 have had vulnerability fixes since then.

The python-3.11 envvar change mentioned above for the 102 series is required.

Firefox-113.0 does not need any fixes for GCC-13 libstdc++ header changes.

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 instead of gcc. If you want to do that, look at what Arch is doing.

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 114.0beta

nss >= 3.89.1

if you are using gcc-13, there is a patch at ​https://hg.mozilla.org/releases/mozilla-beta/rev/424a213f8a13 which should be in 114.0b7 whenever that appears - see bmo1831242.

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

Up
Top