Firefox Wayland development in 2021

I swear, no more crashes on Wayland!

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).

15 thoughts on “Firefox Wayland development in 2021

  1. Thanks Martin! Great work, especially the hard bits around popups, c-p and DnD.
    As I’m too lazy to write my own blog post, excuse me for taking the freedom to add some related highlights in 2021:
    – Hardware Webrender is now used almost everywhere, with some places where we fall back to Software Webrender. The old layer compositor (“Basic” and “OpenGL”) has been removed in Firefox 93, greatly reducing the complexity of the graphic stack. This is especially import on Linux, as we don’t have as much capacity for fixing bugs and testing as on other platforms.
    – On X11 we’ll finally switch from GLX to EGL, making some improvements from the Wayland and Android backend available there, notably faster WebGL via DmaBuf and partial damage. This will ship in 94 on Mesa, Nvidia will follow. This should also help reduce complexity in the long run.
    – There is a new experimental Wayland backend, aiming to increase power efficiency similar like we do on CoreAnimation(MacOS) and DirectComposition(Win). It can be tested by enabling `gfx.webrender.compositor.force-enabled`.

    Like

  2. Awesome work! It’s really great seeing Firefox improve its Wayland support.

    A couple questions:

    Will it ever be possible for Firefox VA-API to work in Fedora by default? Currently VA-API requires ffmpeg, which doesn’t seem like it could be shipped in Fedora by default anytime soon for patent reasons.

    After these next few cycles, how feasible do you think Wayland mode by default will be?

    Like

    1. – VA-API can be default for VP8/9 and AV1 which does not need patented ffmpeg (https://bugzilla.mozilla.org/show_bug.cgi?id=1660336). It also depends on your drivers, for instance AMD supports that without any additional drivers from rpmfusion.
      – Default Wayland mode depends on testing which needs mutter 41.0 (will be in Fedora 35) and we need to use it in Mozilla try to test builds. There’s a tracking bug for it – https://bugzilla.mozilla.org/show_bug.cgi?id=1543600.

      Like

  3. Thanks for all your and other’s hard work! The Fedora 34 KDE spin defaulted to Wayland, and by setting MOZ_ENABLE_WAYLAND=1 Firefox using Wayland has worked pretty well. Occasionally copy & paste stops working between different pairs of applications; I haven’t been able to track it down, and pasting into an intermediate app like Kwrite is a workaround.

    What’s the status of Thunderbird on Wayland? I read somewhere that it isn’t supported, but it has worked for me.

    Like

    1. – Clipboard should work better in Firefox 94 by default. You can test that early in Firefox 93 (should be released on Oct 5) – set widget.wayland.async-clipboard.enabled to true at about:config and restart browser.
      – Thunderbird uses latest ESR line code so it’s on the same state as Firefox 91. You can expect some issues with popups and clipboard but should work in general.

      Like

  4. Thank you for all those years of making Firefox great on Linux. I particularly appreciate all the hard work that went j to the Wayland transition that has made my mixed DPI setup work seamlessly.

    Like

  5. Thank you for the update. I am really interested in the progress of VAAPI sandbox implementation. As for hardware acceleration, this seems to be one of the last major lacks of firefox.

    Like

  6. > Plus there are some interesting bugs in Wayland protocol or Gtk

    The linked bug definitely looks like a bug in GDK, not the wayland protocol, as the xdg_popup interface specifically has a request for repositioning the popup.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create your website with WordPress.com
Get started
%d bloggers like this: