Firefox Wayland development in 2021

It’s been long time from my last update about Firefox news on Linux and I’ve finally got some time to sum up what we’ve been working on for last year and what’s coming. There haven’t been introduced any new exciting features (from Linux perspective) for the last year but rather a hidden but important changes.

From Linux desktop developers perspective 2021 is a year of Wayland. KDE has been shipping decent Wayland compositor which becomes default for Fedora 34. It’s actually pretty fast and gives you smooth feeling of “good old times” with X11/Gtk2/name-your-favorite environment where any graphics change was just instant without lags or slow transitions. I must mention Robert Mader who created a new Firefox Wayland SW backend for the KDE.

As major desktop distro (Ubuntu) is slowly moving to Wayland we’re getting more and more Wayland/Firefox users. Even notorious troublemaker (NVIDIA) decided to step in and support it.

What’s done for next releases?

It’s good that Wayland market share is rising but we also need to make sure that Firefox is ready to run there without any major issues and matches its X11 variant. There are two major areas where Firefox is behind its X11 counterpart – clipboard and popup handling. It’s given by some Wayland protocol features where we can’t simply duplicate the X11 code here.

Clipboard on Wayland is similar to X11 one but we need to translate Wayland asynchronous clipboard to Firefox/Web synced one. I tried various approaches but the best one seems to be just use the asynchronous Wayland clipboard as is and implement some kind of abstraction over it. That was implemented in Firefox 93 an it’s going to be shipped by default in Firefox 94.

On the other hand popups are the most annoying thing we have to implement on Wayland. Firefox just expect any popup can be created any time without its parent (or use main window as a parent) but Wayland requests strict popup hierarchy. It means every window can have only one child popup. When more than one popup is opened it has to be attached to the previously opened popup which becomes a parent for it. And when any popup in the chain is closed the popups must be rearranged to keep the chain connected. This involves all kind of popups like content menus, tooltips, extensions popups, permissions popups and so on. Plus there are some interesting bugs in Wayland protocol or Gtk so excitement/frustration is guaranteed and basic popup implementation becomes extraordinary challenge where small changes can introduce various regressions. Despite the ‘fun with popups’ the popup tracker is almost clear and we’ll ship it in Firefox 94.

One of main Wayland feature is support of monitors with various DPI/scale factor together. Fedora default compositor Mutter shows here a creative approach and reports screen sizes differently than other compositors. As we really want to know screen sizes Firefox tracks monitor changes from Wayland directly and find correct screen by matching screen left top corner point – which fortunately stays stays same for all compositor. We also stop painting Firefox window when screen scale changes so you should enjoy seamless experience on systems with various screen sizes with Firefox 93.

Future plans for Firefox 95

Firefox 95 development cycle begins next ween and I’m going to look to drag and drop which has been partially broken for long long time. Some Wayland specific fixes are already in Firefox 94 but we need to rework some parts to correctly copy files from remote destinations (like inbox) to local filesystems, fix names of dropped files or do tab preview of moved tabs. There are also new interesting compositors bugs as usually

Future plans for Firefox 96

Firefox Wayland port is generally done and there isn’t any big difference between X11 and Wayland variant at least on GNOME which Fedora uses as default environment. We’re fixing minor bugs and keep eye on user reports.

For next quarter I’d like to look at GPU process for Wayland. GPU process is running tasks related to graphics hardware and shields browser from HW drivers crashes. It’s also place where VAAPI video decoding should be run and will be properly sandboxed there (right now VAAPI is run in content process along general Firefox code, it’s restricted by content sanbox which leads to various VAAPI code crashes and failures).