Q3 Firefox Linux update

Let’s highlight some updates of Firefox development from Linux perspective for last three months.

Wayland backend is gaining momentum at Mozilla upstream. It’s enabled by default in Fedora/Arch Linux but Mozilla is a bit hesitant and runs Wayland for Nightly/Beta only. Mozilla official binaries, Ubuntu/Snap and Mozilla/flatpak switches to XWayland mainly due to missing test coverage of Wayland builds.

But Mozilla migrates its testsuite to Ubuntu 22.04 which also involves Wayland testing (Bug 1813588) so let’s hope we see Wayland in release soon (Bug 1752398). Indeed there are still some Wayland bugs to fix and we keep an eye on it.

Dbus-glib is no longer needed by Firefox to build. This old dependency from Gtk2 times was removed in Firefox 120.0 where we switch to Gio DBus interface and async implementation based on MozPromise. Dbus-glib can be removed from build roots for good and that helps mainly to flatpak packaging.

Kiosk mode has a new feature – with ‘–kiosk-monitor’ parameter you can place Firefox kiosk window to a specified monitor. That supports Wayland/kiosk environments and mutihead setup where one box covers more displays. We also switch to fullscreen immediately after Firefox start to make sure we reliably cover whole screen in kiosk mode.

Idle monitor/service was implemented by org.gnome.Mutter.IdleMonitor DBus interface. Former X11 version crashes and doesn’t work on Wayland. I may look at KDE/Sway interfaces too.

I also investigated broken Gnome Shell search service in Fedora and found out that Firefox DBus search interface needs to be ‘Activatable’. That involves to implement org.freedesktop.Application DBus interface, ships corresponding service file at /usr/share/dbus-1/services/ and has application desktop file in correct format (org.mozilla.firefox.desktop instead of recent Fedora plain firefox.desktop).

So I renamed Fedora Firefox desktop file to org.mozilla.firefox.desktop and bundled DBus service search file and everything looked okay except … Gnome Shell default launcher has hardcoded ‘firefox.desktop‘ so Firefox was removed from default applications :D. Well, desktop file change is allowed for new releases only. Lesson learned.

But there’s a way. You can use plain firefox.desktop name but you need a binary service launcher at /usr/share/dbus-1/services/ file so DBus can run the service on demand. As we don’t want to run Firefox for every Gnome search I put simple ‘/usr/bin/false’ there and oala! Search works and Firefox is still in Gnome taskbar.

But, well, desktop is not just a Gnome. KDE/Plasma has also a vote and just can’t stand such level hack and simply crashed. I don’t blame it, non-canonical desktop file name with DBusActivatable flag may be too much for poor launcher. Nobody is perfect.

So right now we have broken Gnome search provider but I know where the problem is and look forward to fix it for Fedora 40, with desktop file rename and implementation of org.freedesktop.Application DBus interface.

And that’s all for Q3, let’s see next quarter.

Firefox on Linux update

It may look like Firefox development is stalled and frozen but nothing could be further from the truth. 22 300 patches landed in Firefox Mercurial repository since new year and we keep hacking 😀

Let’s look what’s new in Firefox on Linux and what could be interesting for Fedora users.

  • Large WebRTC update was merged with DMABuf screen sharing and xdg camera portal support, both developed by Jan Grulich. It should speed up screen sharing via. portals (used by Wayland, Snap and Flatpak) and enable new webcams on Linux.
  • VA-API was enabled for Intel GPU on Firefox 115.0. AMD is delayed due to various driver bugs but you can force enable it by setting media.hardware-video-decoding.force-enabled at about:config. VA-API state is printed at about:support page now.
  • David Turner implemented video hardware decoding support for H.264 on a Raspberry Pi 4 via V4L2-M2M and there’s ongoing work to enable VP8/9 too. If you have an arm with HW video decoding, try it in next Firefox 116.0 (or recent Beta).
  • Emilio Cobos Álvarez – fixed many Linux/Gtk style bugs like wrong colors, menu round corner rendering, titlebar rendering and also lots of Wayland bugs. He unified Firefox main window rendering on all desktops (we use client decorations – CSD – now) and have fixed regressions on desktops like XFCE/TWM.
    The style bugs are especially tricky ones as we removed X11/Wayland display connection from web content processes (due to security) and we can’t use native styles directly then.
  • Firefox 116 allows you to create Wayland or X11 exclusive builds. It means you can build Firefox without X11 (or Wayland) dependency which saves space and resources. Also you don’t need anymore Wayland build to run DMABuf and VA-API backends.
  • Mozilla started to implement Firefox tests on Wayland (along with testsuite migration to Ubuntu 22.04). It allows to ship Wayland backend by default with Mozilla binaries and Ubuntu/Snap and reduces regressions during development.
  • Fedora ships Firefox 115.0 with PGO/LTO optimization again (built by GCC) after long period of breakage. Mozilla/clang builds are still a bit faster than GCC ones (Mozilla binaries give me ~ 200 points in Speedometer2.1 while Fedora ones ~ 190 points) but GCC binaries are slightly smaller (130 MB vs. 150 MB).

    But it’s still much better than non-PGO ones, Fedora Firefox 114.0 did only ~140 points in the benchmark.

    Just out of curiosity I tested Chrome browsers too. Fedora Chromium gives me ~140 points and official Google Chrome reached ~ 200 points. Looks like Fedora Chromium need some tweaks too :D.

No one fights alone. A guide to your first Firefox patch on Linux.

Have you ever hit an annoying Firefox bug and want to fix it? You’re right here. Firefox is a great open source project with many volunteer contributors, large community and any patches and help is very welcome.

This post aims to help you with your first patch to Firefox and become an active Firefox contributor.

Get and build Firefox sources

First of all you need to get Firefox sources and build themon Linux. Ubuntu is a natural choice of many but I use Fedora as it’s Wayland leading distro and I’m also Red Hat employee. It doesn’t matter much because Firefox installs its own build environment.

Firefox development happens on nightly which is the latest up-to-date sources and all changes goes there. For start you need mercurial package installed.

Download latest Firefox sources to src directory by mercurial:

hg clone https://hg.mozilla.org/mozilla-central/ src

A finished Firefox build may need ~ 40GB of free space so don’t be surprised. It’s quite a beast 😀

Create .mozconfig file in src directory to set build conditions. Correct values are selected automatically so you don’t need to care much about it now. You can use mine generic one for optimized builds:

. $topsrcdir/browser/config/mozconfig

mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1

ac_add_options --disable-debug
ac_add_options --enable-optimize

And one for debug / non-optimized builds. That’s suitable for debugging:

. $topsrcdir/browser/config/mozconfig

mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1

ac_add_options --enable-debug
ac_add_options --disable-optimize

Then you go to create a build environment and download build tools for it. Run bootstrap and select Firefox for Desktop there:

./mach bootstrap

That downloads all requested tools from Mozilla and put them to ~/.mozbuild directory. It also configures Mercurial to work with Firefox sources. If you decide to quit or you want free disk space, just delete .mozbuild and src dirs.

You should be ready to build Firefox from sources now:

./mach build

When build is finished a new firefox build is in src/objdir/dist/bin directory and you can run it there.

Firefox hacking

Mozilla provides powerful tool Searchfox where Firefox sources may be browsed and investigated. From Linux/Gtk perspective some interesting code parts are:

  • widget/gtk – there’s Firefox/Linux/Gtk integration point here named toolkit and almost all Linux related code is located here. Corresponding Bugzilla component is Core :: Widget/Gtk where most of Linux bugs are filed.
  • widget/gtk/nsWindow.cpp – every Firefox window (main browser window, popups, tooltips etc.) have its nsWindow object. It creates GtkWindow for browser, handles Gtk signals and so on. Look at nsWindow::Create() for instance.
  • widget/gtk/DMABufSurface.cpp – implements dmabuf based surfaces. It’s used for various Linux/HW operations like video playback and WebGL rendering.
  • toolkit/xre – Firefox startup code. Set’s up GdkDisplay, wayland/x11 connections and remote startup code.
  • dom/media/platforms/ffmpeg – ffmpeg video playback implementation, VA-API related code.
  • gfx/thebes/gfxPlatformGtk.cpp – Set’s up gfx environment on LinuxGtk. Initilizes and configures WebRender, VA-API, DMABuf and related features and enable/disable them according to actual hardware.
  • gfx/gl – EGL/GLX related code, contains OpenGL setup for Linux (and other systems).

You can use there hints as starting points for further investigation.

Mercurial mini-howto

Mercurial is a VCS used by Mozilla. I’ve never been good at it and both Git and Mercurial are still a mystery to me. But don’t worry, you need only a small subset of Mercurial commands to hack Firefox and submit your patches.

Show all changes in your sources:

hg diff

Revert all your changes:

hg revert --all

Or revert specified files:

hg revert file1 file2 ...

Commit your changes:

hg commit -m "commit message"

This is the most important Mercurial command you use. It saves your changes locally and you can submit them to Mozilla for review later.

Mercurial commits all changes by default but you can ask to commit selected files only:

hg commit -m "commit message" file1 file2 ...

After commit the change gets a revision number. You can print that by Mozilla hg wip helper:

hg wip

And you show complete patch (message and changes) by:

hg log -v --patch -r revision_number

Now let’s look at commit message. It’s important part of the commit and has following format for Firefox project:

Bug XXXXX - What changed r?reviewer_name

Look at Bug 1818517 and D172914 patch. They’re a good example how the commit message looks like:

Bug 1818517 - Ignore crossing-due-to-grab-start r?stransky

Bug field tells Mozilla tools where to attach your patch while r? field selects who is going to check and ack the change. You always need to specify these two entries.

Without bugzilla number and reviewer name the patch can’t be uploaded or will hang unnoticed there.

The patch reviewer is a key person for your contribution. He/she may direct you how to improve the patch, ack it and eventually check it into project. Sorrect reviewer selection may be tricky and could discourage new contributors.

If you create a new patch for Linux you can always select me (r?stransky). Reviewers for other parts of Firefox are listed here.

Submit your patch for review

So we have a patch committed to your local repository and want to upload it to Mozilla for review. First you need to create account in Bugzilla (bug tracking system) and Phabricator (patch tracking) and install moz-phab tool to submit your patches.

Let’s say we have Bugzilla/Phabricator installed and moz-phab is working. It’s time to submit your first patch. Make sure you enabled Mozilla mercurial extensions in mach bootstrap command above. If not please run it again and enable it.

hg wip command lists patches/revisions in nice format and you can select what to submit:

To submit our patch for Bug 1818517 use moz-phab tool with patch revision numbers:

moz-phab submit d67996f50ead d67996f50ead

and you have your first patch uploaded.

More useful Mercurial commands

Update your sources to the latest ones:

hg pull
hg up central

Switch sources to any revision/branch from history. Use hg wip to get revision number and use hg up to switch:

hg up d67996f50ead

Rebase tool allows you to re-arrange patches across branches, make patch stream linear or rebase your patches to latest trunk. It rebases single patch or more changesets.

In case of collision a merge tool is called. I personally use Meld tool as vimdiff is difficult to use for me. Use hg rebase –help to get complete options list. I usually use:

hg rebase -s source_revision -d dest_revision -k

histedit is a great tool for commit management:

hg histedit

It allows you to re-arrange, merge and drop individual patches and change commit messages or show individual patches.

Where to start?

Wanna help with the project and fix bugs reported by other people? Cool! Bugzilla is your friend there are trackers related to Linux/Gtk here:

And that’s all! Don’t hesitate to join Mozilla Matrix chat, have fun and become member of Firefox developer community. If you’re blocked on any step listed here, drop me a note or ask on Mozilla chat.

Firefox, VA-API and NVIDIA on Fedora 37

Image comes from https://www.nvidia.com/en-us/about-nvidia/legal-info/logo-brand-usage/

Some time ago I got borrowed NVIDIA GeForce GTX 1070 from my employer (Red Hat) and I finally managed to put it to a workstation instead of my own AMD RX 6600 XT.

I installed proprietary drivers from rpmfusion and to my surprise everything worked smoothly (except Atom on XWayland). Both Wayland and X11 Gnome sessions popped up, Firefox picked up HW accelerated backend (WebRender) with DMABuf support so it’s time to check VA-API.

Thanks to nvidia-vaapi-driver by Stephen “elFarto” Firefox may directly decode video on NVIDIA hardware. The driver translates VA-API calls from Firefox to VPDAU used by NVIDIA. I think you also need a decently fresh NVIDIA drivers which supports DMABuf (which is used to transfer decoded images between Firefox processes and render them as GL textures).

I hit three bumps on the road. First one is Firefox RDD sandbox. Firefox runs media decode in extra process (RDD) which restricts where decoder can access. It was adjusted by Mozilla folks for VA-API decode on Intel/AMD but NVIDIA needs some extra tweaks. Right now you need to disable the sanbox by MOZ_DISABLE_RDD_SANDBOX=1 env variable.

Next one is a bug in recent NVIDIA 525 driver series (which I got from rpmfusion) and I needed to use direct mode (whatever it is).

Last issue may be in Firefox itself. Broken graphics hardware may freeze whole browser on start or spread coredumps on every start. That’s being worked on as Bug 1813500 and Bug 1787182.

There’s a complete how-to for Firefox/NVIDIA/Fedora 37 available on Fedora wiki.

Nvidia-vaapi-driver playback performance is similar to what I see on AMD/Intel. It also correctly handles decoding of intermediate frames which is recent AMD NAVI2 bug (Bug 1772028, Bug 1802844) so the playback is smooth and I haven’t seen any glitches or CPU usage peaks.

There are few options for NVIDIA users how to run it.

If you have a workstation (or laptop) with one NVIDIA graphics card, it’s quite simple. On Fedora 37 you boot on noveau drivers and then install NVIDIA drivers from rpmfusion. With the proprietary drivers both Wayland and X11 Gnome sessions work fine (anyone to test KDE?) and hardware acceleration is enabled.

A bit different scenario comes with integrated Intel device and secondary NVIDIA one. I don’t see any reason why to use NVIDIA as Intel works pretty well with Wayland, VA-API and X11/EGL. But if you really want to set NVIDIA as primary, X11 may be better for you. Wayland on secondary NVIDIA GPU is supported by Sway Wayland compositor only which is a bit geeky (or I’m just too lazy to learn new shortcuts and get used to a new environment).

Anyway, if you need to use NVIDIA as your primary GPU, there’s a hope for you (and it’s not due to me). Give it a try and report eventual bugs at Mozilla NVIDIA VA-API bug tracker.

Firefox with VA-API for brave Fedorans

A rocket propelled butterfly? – https://bugzilla.mozilla.org/show_bug.cgi?id=1772028

It’s been a long journey since the first VA-API implementation in Firefox. Two years ago Firefox 77.0 come to Fedora with accelerated video playback on Wayland which was more a tech preview than a working solution.

Since then X11 support was added, fixed many bugs, AV1 decoding was implemented so we can claim VA-API code as mature enough to enable it for testing in Firefox Nightly 103. As we don’t want to scare peaceful Ubuntu users and grandmas watching their favorite show, VA-API is enabled in Nightly channel only and stock Firefox 103 won’t be shipped with that.

But ‘Real Men‘ wants more challenge. ‘Quiche Eaters’ can use polished software, LTS distros or even Mac. That’s nothing for adventurers running on the edge. Thus new Firefox updates (Fedora 35, Fedora 36) has VA-API enabled by default ahead of upstream to get what you asked for, brave Fedorans.

Along with a bunch of upstream VA-API backports I also added a fix for mozbz#1735929 to make life easier for those who did a life mistake with NVIDIA hardware. I hope you’ve got a lesson and your next card will be AMD.

And how to fruitify it? It’s embarrassing it doesn’t need any complicated, cryptic, powerful, unforgiving and dangerous edits of Firefox about:config preferences, setting env variables on terminal or midnight vows. If VA-API is configured property Firefox just takes it and claims at about:support page.

VA-API is enabled

More details are available at https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Design a site like this with WordPress.com
Get started