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 seems to want to create a new profile when coming from 78esr, but using 'firefox -P' allows 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 is 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 tings 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 can 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 is also 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 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 (I think v16.14.2 was the last vulnerability fix). 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

rustc needs to be >= 1.59.0, tested with 1.60.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 changes 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.

Additionally, at the moment two seds are being used to fix code incompatible with python-3.11. The first of these,

 grep -rl \"rU\" | xargs sed -i 's/"rU"/"r"/'

fixes various files under 'python/'

and the second fixes xpcom/idl-parser/xpidl/xpidl.py

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 108.0 series (latest upstream stable)

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

The shipped libpng is marked for automatic updates, but only when firefox is in alpha - in 107.0 the shipped version is still 1.6.37 but it works fine with 1.6.38 (unsurprising, that was not intended as a breaking change)

The shipped libvpx has been updated to v1.12.0

libwebp should be updated to >= 1.2.4

nss >= 3.85.0

nspr >= 4.35

rustc >= 1.63.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.

Of the changes mentioned above in the 102 series for python-3.11 (envvar, two seds) the envvar is needed but the seds are not needed when building 107.0 or later with python-3.11 although a lingering match for the xargs sed remains in view testing/web-platform/tests/tools/third_party/py/py/_path/svnurl.py

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

ICU was bumped to 72.1 in the inital betas but has now been reverted to 71.1.

The shipped libpng is now 1.6.39, updating to that is recommended,

nss will now need to be >= 3.86

I will remark that in starting 109.0b3 after previously running 108.0 I was surprised that it lost all the tabs I had had open.

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