Firefox 124 supports GNOME titlebar actions

On GNOME Firefox runs with disabled system titlebar by default. It saves horizontal space on wide screens but also removes control over window, traditionally provided by Window manager and desktop environment.

GNOME allows to set titlebar actions by gnome-tweaks tool, you can define window actions for double click by first mouse button, middle click and secondary button. These choices are not followed by Firefox if system titlebar is off because Firefox integrates titlebar with browser tab strip and performs build-in tasks like open/close new tab or toggle maximize.

However Firefox 124 improves it and follows mouse button double click action defined by GNOME so you change it as you wish.

You also can define titlebar action for middle mouse button click, which opens a new tab by default. Set widget.gtk.titlebar-action-middle-click-enabled at about:config and it should work then.

Wayland proxy load balancer

Updated Dec 23

Wayland clients (applications) may face various difficulties not primary caused by them. There are three main Wayland compositors (Mutter/Gnome, KWin/KDE and WLRoots/Sway) and every compositor behaves differently in some corner cases not exactly defined by Wayland standards (or bents the specification somehow).

In X11 world an underlying X.Org implementation is the same for every desktop environment and there are differences introduced by window managers. Wayland merged window manager (like Metacity) and renderer (X11) to one block.

One of Firefox Wayland top crash bug is a Lost connection to Wayland compositor one.

Mutter (and maybe other ones) terminates Wayland client if it’s recognized as stalled. It usually means Wayland client doesn’t read messages from Wayland display socket fast enough and compositor message output buffer is full. It may be a bug in application itself (an event loop is not processed) or it’s caused by input devices like 1000 Hz mouse which generates too many events.

Unfortunately Wayland protocol doesn’t implement any kind of display connection management. Once the connection is lost / disconnected, there isn’t any way how it can be restored and Wayland client is terminated. The most visible example is Wayland compositor crash which takes down all applications, there isn’t any recovery point available.

There are various discussions going on [1],[2] but they’re stalled too 😀 as well as discussion about PIP – Picture-in-Picture Wayland protocol extension implementation [3].

But Firefox needs to solve the crashes caused by message jam right now as it’s shipped to wide audience. An initial idea popped out in discussion to create a proxy between Firefox and Wayland compositor to cache messages and prevent compositor message queue overflow. It’s very simplified case of WayPipe which routes Wayland communication over network and adds network transparency to Wayland protocol.

There’s initial successful proof-of-concept written in Rust and I implement it in C++ as wayland-proxy module which can be shipped with Firefox (mainly because my Rust knowledge is non-existent).

Wayland-proxy can be used as stand alone application or library included in Wayland application and it’s shipped with Fedora Firefox 121.0 right now and let’s see how it works.

UPDATE: Thanks to the valuable feedback at comments, it’s definitely worth to looks at it! There are more issues which needs different approach and Firefox problem also depends on Gtk3 and it’s way of handling Wayland connection. I was also pointed to Qt 6.6 robustness project which implement Wayland reconnection on Qt toolkit level.

Mozilla ships Firefox 121.0 with Wayland enabled

Even my hometown Brno has its own Wayland 😀

Firefox on Linux hit another milestone as Mozilla defaults to Wayland backend instead of XWayland X11 emulation in Firefox 121. It’s a logic step as XWayland emulation introduces bugs from both Wayland and X11 worlds together so better run Wayland directly.

As Fedora has provided Firefox on Wayland backend for years, this change affects mainly Ubuntu and its Firefox/Snap users (if Canonical decides to follow Mozilla here), Firefox shipped as Flatpak and next Firefox ESR and Thunderbird releases.

And what to expect? Beside all the goodies I need to mention Wayland differences and regressions from X11.

• Wayland doesn’t allow applications to position itself on desktop and it can’t place itself on a particular workspace.
  
  It means Firefox session restore feature works differently on Wayland and all Firefox windows are restored on first workspace.
• Wayland client can’t place itself on top, above of other clients, which is another Wayland security feature. It affects Firefox Picture-in-Picture (PIP) windows, they can’t be placed on top by Firefox itself.
  
  You need to guide Wayland compositor to keep it there. Fortunately a GNOME extension may be installed for it and KDE allows to create a window rule.
  
  Or you can click by right mouse button on PIP window and select ‘Always on Top’ option there.
  
  There’s ongoing discussion about universal PIP Window interface as Wayland protocol extension (similar to PIP on Android) but we’re far from general agreement here.

And if you feel Wayland is too restrictive for you while it’s missing any benefit it can be disabled in Firefox by MOZ_ENABLE_WAYLAND env variable. Just add

export MOZ_ENABLE_WAYLAND=0

line at .bashrc file (or similar one for different shell) or run Firefox from terminal as

MOZ_ENABLE_WAYLAND=0 firefox

or add it to /usr/bin/firefox launch script.

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.