firefox-78.0esr

[ken@…]

The second available candidate build for 78.0esr is now available, so before the release next week I'm creating this to document some items of interest.

1. 78.0esr is different from 78.0 in three ways:

· the version is labelled as 78.0esr instead of 78.0

· extensions do not need to be signed by the trusted root (I guess that is for organizations which create their own extensions)

· some nightly options for enabling webrender have been removed, making the tarball slightly smaller.

The nightly options are o convcern, esr cannot be nightly.

Allowing unsigned extensions for the ordinary esr user seems like a bad idea in terms of security: "Why don't you download and install this handy extension of mine ?".

Fortunately, it can be fixed with a sed to revert that change:

sed -i -e 's/Disable/Enable/'      \
 -e '/^MOZ_REQUIRE_SIGNING/s/0/1/' \
 build/mozconfig.common

As (mostly) noted in the wiki, the accepted build options have changed:

· --disable-webm is no longer accepted, but webm should continue to be recommended because there is a shipped version.

· --disable-startup-noification is no longer accepted, therefore startup-notification becomes required.

· --enable-system-sqlite is no-longer accepted. I guess that after the issue a few moths ago where they were found to be using an internal feature they've decided to keep their own version which works for them. Unlike the situation several year ago where mixing shipped sqlite in firefox and system sqlite in other things apparently caused problems, so far this seems to be ok.

· --with-system-bz2 is no-longer accepted, I assume they've got rid of bz2.

With the first esr candidate I've looked at the difference between using mozilla's preferred clang, clang++ (preferred as in "one toolchain for all platforms") and gcc, g++.

On my machine, the build sizes are consistent for each toolchain across several builds. It is not needed to specify the full set of 'CC=clang CXX=clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib' to use clang and clang++ although specifying all does give a slightly smaller and slower build than just using clang and clang++. In either case, the default bfd linker is used.

Traditionally, llvm and therefore clang has been slow to add security hardening. I think that the available hardening flags for x86 (although not for aarch64 and probably not for 32-bit ARM) are now probably the same as in gcc - no idea if they work as well as in gcc, but they seem to be accepted.

So, I tested a series of builds with both gcc, g++ and clang, lang++.

Using gcc, the build and install total 4.9 GB (184 MB installed), using clang the build and install is 77MB smaller at 4.8GB (180 MB installed). I confirmed that neither is using LTO (except that rust code passes -Clto in two places) - that would probably need a PGO build (see Arch) which will take a lot longer.

So, using clang might be a possibility. But repeated tests indicate it is a slower build. Since a BLFS user should (now) expect to update firefox on a 4-weekly cycle, the extra time to build with clang doesn't seem beneficial (and I cannot see that a marginally smaller install will start up noticeably quicker.

Anyway, I did 5 builds of each, with SBU rounded to next unit, and also rounded to three decimals, then averaged.

gcc, rounded to whole SBU 31 33 32 31 32 avg 31.6 and to three decimals 30.98 32.657 31.507 31.418 31.502 avg 31.613

clang, to whole SBU 35 34 33 32 34 avg 33.6 and to three decimals 35.35 33.597 33.326 31.625 33.763 avg 33.532

So the average is 32 SBU with gcc, and 34 SBU with clang.

Yes, this is about 50% slower than firefox-68.9.0.

The webrender items in the diff from 78.0 caused me to look at that: it is still opt-in, but my preliminary tests suggest it can be worthwhile. I've got to do some more tests on a low-end intel (on my haswell i7 it uses typically 20% of 1 cpu, instead of 4 to 5% on ATI R600 and amdgpu), but I epect to add details to the configuration section.

[ken@…]

I've now tested WebRender on my i3 skylake, it seems good - typically, CPU percentage for Web Content is reduced, but a similar percentage is used for 'GPU'. I had not realised that the 'RDD' process (Remote Data Decoder - used for many youtube videos, probably those using dav1d) can appear whether or not WebRender is activated.

The only downside (for machines with integrated graphics or APUs and a small amount of RAM) is that more RAM might be used.

Brief summary of enabling WebRender:

For machines with ati, intel, nvidia (nouveau, I assume) and mesa-18 or greater, in about:config change gfx.webrender.all to True and restart firefox (e.g. killall -HUP). about:support should now show, under Graphics, compositor WebRender (insteado f Basic). Details of webrender at ​https://www.ghacks.net/2019/05/20/firefox-webrender-rollout-begins-with-the-release-of-firefox-67/ - in 68 it was still very experimental, and I believe not applied to all now-allowed GPUs.

I will also mention that 78 wants a newer profile than 68 (the last known change was around firefox-73), but starting firefox-78 with --allow-downgrade seems to recover the existing settings.

[ken@…]

Oddly, although I had enabled WebRender in a beta version of firefox, the 78.0esr release had it disabled and thought it should use the old 68 profile (i.e. did not start unless 'firefox -P' was used). I deleted that old profile when restarting after re-enabling WebRender, but the tabs I had had open were lost.

[ken@…]

Updated at r23344, but I'm sure I've probably forgotten something.

In any case, I'll keep it open until the release notes for both 78.0 and 68.10 are released - usually there are fixes for memory corruption.

[Pierre Labastie]

Tried to install, but it fails early with (just the end of a long backtrace):

  File "/usr/lib/python3.8/sqlite3/dbapi2.py", line 27, in <module>
    from _sqlite3 import *
  File "/sources/firefox/firefox-78.0/build/mach_bootstrap.py", line 475, in __call__
    module = self._original_import(name, globals, locals, fromlist, level)
ModuleNotFoundError: No module named '_sqlite3'

What seems weird is that the from _sqlite3 import * line is from a system installed file, but the call seems to go through a source file. Anyway, short googling showed the _sqlite3 is built by the Python build system if the sqlite headers are present. So I rebuilt Python3. And the build (still running) seems to have gone past that point...

[Pierre Labastie]

firefox built after that, is able to display a youtube video... Not much more I can ask.

I think python3(blfs) should be recommended for firefox, and sqlite3 recommended for python3(blfs). What do you think?

[ken@…]

Replying to pierre.labastie:

firefox built after that, is able to display a youtube video... Not much more I can ask.

I think python3(blfs) should be recommended for firefox, and sqlite3 recommended for python3(blfs). What do you think?

Sorry about that, but thanks for debugging it. I would never have hit that because the first package I build after LFS is sqlite3, and very shortly after that I rebuild python3. I'll add it.

[ken@…]

Actually, sounds as if BLFS python3 should be required. I've done that in r23348. The main Release Notes are now out, but the links to the security fixes only go as far as firefox 77.0 at the moment.

[ken@…]

Release notes are at last available. For 69.10 ​https://www.mozilla.org/en-US/security/advisories/mfsa2020-25/ - a couple of use after free and an information disclosure, all rated as high. I'll belatedly note 78.0esr as Security fixes in the changelog.

[Bruce Dubbs]

Milestone renamed

[Bruce Dubbs]

Milestone renamed