1749174 - Consider enabling wayland if available

Status: RESOLVED FIXED

(Core :: Widget: Gtk, task)

Description

[Emilio Cobos Álvarez [:emilio]]

Since Fedora and Ubuntu are shipping it Wayland by default, and Firefox-on-wayland too, it seems we'd get more relevant testing for our users if we enabled it on official builds too.

Is there any reason we shouldn't do that?

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1749174 - Enable wayland on supported environments by default on Nightly / Early Beta. r=stransky!,jrmuizel!,aosmond!

There are pros and cons of doing this. Pros are:

• Both Fedora and Ubuntu ship this by default. I haven't run the
  numbers but my guess is that with those two distros the amount of
  users on Wayland will probably be greater than the amount of users on
  XWayland.

• Wayland touchscreen support, and a bunch of other features that
  XWayland doesn't have (I'm probably missing a bunch).

Cons that come to mind are:

• The main one is that we're still testing X11 on automation, though it
  is my understanding that Martin has Wayland tests running on the
  Fedora automation. I'd understand if we'd want to defer this until we
  have Wayland tests running on the Mozilla automation (bug 1725245),
  though arguably that hasn't stopped us from shipping X11+EGL (though
  arguably a smaller change, too).

• I think the other annoyance of Wayland is the lack of proper PiP
  support (bug 1621261): Right now users need to right-click on the PiP
  Window.

There (most likely) will be others pros and cons (and if we can't come
up with others this patch should allow us to gather more feedback in
Nightly / early-beta). Thoughts?

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1749174 - Make the wayland-enabled check easier to follow. r=stransky

This shouldn't change behavior.

Comment 3

[Darkspirit]

Yes, please!

• This would fix at least bug 1630251 and bug 1744389 (its patch could be backed out for causing bug 1745530 and just leave the Mesa log entry for X11 users. VAAPI anyway spams the log.)
• IIUC, Wayland would also work on Nvidia before 495 (EGLStreams build option; bug 1646135 comment 19), when not using gfx.webrender.compositor.force-enabled which requires Dmabuf.
• Nvidia 495 Wayland users would get Dmabuf WebGL (bug 1735929). bug 1716049 and bug 1736245 do not occur on Wayland.
• In case there is a need, Snap users can already force Xwayland with DISABLE_WAYLAND=1. Mozilla binary users could set MOZ_ENABLE_WAYLAND=0.
• bug 1748921 does not occur on Wayland.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Mike, do you have telemetry numbers about Wayland / X11 share?
If we enable Wayland on Nightly/Beta only and keep it disabled for Release, we'll test and ship completely different setup which is wrong. We need to test what we ship.

Comment 5

[Robert Mader [:rmader]]

Maybe we can make it a Nightly Experiment?

Comment 6

[Darkspirit]

An experiment to "test" what is already shipping by default downstream?

Now:

• Nightly&Beta
  • X11 users test X11
  • Wayland users test X11 (Xwayland) by default. Some users test Wayland with MOZ_ENABLE_WAYLAND=1 env var.
• Stable&ESR
  • X11 users get X11 (Nvidia, i3)
  • Wayland users (Gnome Wayland is default on Debian/Ubuntu/Fedora for Intel/AMD) get
    • [not officially tested] Wayland on the two most popular distributions, Ubuntu (deb+snap) and Fedora.
    • X11 (Xwayland) elsewhere (e.g. Debian).

Then (this bug's outcome):

• Nightly&Beta X11 users test for Stable&ESR X11 users: This should largely be Nvidia (would decrease) and i3 users.
• Nightly&Beta Wayland users test for Stable&ESR Wayland users.

Comment 7

[Darkspirit]

(This bug should be merged as is (without restriction), all of Mozilla's binaries should become what Ubuntu&Fedora are already shipping.)

Comment 8

[Martin Stránský [:stransky] (ni? me)]

(In reply to Darkspirit from comment #6)

An experiment to "test" what is already shipping by default downstream?

Let's see the numbers from Mike to have some info.

Downstream (at least Fedora) can provide fine grained Wayland access - enable on Gnome only for instance as KDE still has some extra bugs or enable on mature enough Wayland environment. Also downstream can ship Wayland patches ahead of upstream to fix regression.

I think Fedora is quite safe but I'm afraid Ubuntu just takes upstream binaries without any additional patches, uses old Mutter etc.

I can imagine to ship Wayland by default on Nightly/Beta for cases where we're 100% sure Wayland is also shipped downstream. That may include Gnome DE, Fedora and Ubuntu >= 21.04. I don't know if it's possible to check mutter version but we should enable Wayland on recent mutter only (say 40+).

With EGL/X11 enabled by default I don't think there's a 'killer feature' missing in X11 builds, we really should not repeat Bug 1739924 scenario.

Also with mutter-41.2-2 (xdg-activation fixes) I can reliably run the Mozilla testsuite and our recent effort should be to fix/update tests for it. I'm already testing that on Fedora 35 and I'm going to update Bug 1578640 with details, file test failures etc.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #8)

I can imagine to ship Wayland by default on Nightly/Beta for cases where we're 100% sure Wayland is also shipped downstream. That may include Gnome DE, Fedora and Ubuntu >= 21.04. I don't know if it's possible to check mutter version but we should enable Wayland on recent mutter only (say 40+).

Right, but the patch only enables Wayland when there's a Wayland display available (and thus the user is running on a Wayland session). I'm happy to limit it to KDE/GNOME since those I test regularly, but if the user is using X11 we won't even get there because we would've bailed out on the WAYLAND_DISPLAY check. So the OS would be shipping Wayland (or the user has gone out of their way to enable it). Anyways agree it's safer to keep it nightly / early beta for now.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/74f5823bed31
Make the wayland-enabled check easier to follow. r=stransky

Comment 11

[Robert Mader [:rmader]]

I'm happy to limit it to KDE/GNOME since those I test regularly

The only other Wayland environments (that we currently care about, i.e. not ChromeOS, WSL or any proprietary compositors) are Weston or wlroots based. In case of Weston it's likely tested embedded environments, in case of wlroots the users are likely quite advanced (and used to debug broken things).
I'd personally be most concerned with old Gnome (3.38 in Debian for example, 3.36 in Ubuntu 20.04) and KDE, and in fact we somewhat can find out the versions, even though only indirectly via the exposed Wayland protocols. I.e. xdg-activation supports means quite new (Gnome: 41), dmabuf-feedback means upcoming versions etc. It's a bit involved to do that early on (before even running glxtest), but doable. If you think it's a good idea I could prepare a patch for that.

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/74f5823bed31

Comment 13

[Mike Kaply [:mkaply]]

Based on my reported telemetry data, X11 share is still really high compared to wayland/xwayland.

50 % x11, wayland/xwayland in single digits on nightly and release.

Related, we really need to figure out the blank window_protocol thing. It's like > 25% of clients.

Comment 14

[Laurențiu Nicola]

That might be because it's pretty hard to enable. I've been using Wayland Firefox for years, and haven't seen any large (or even annoying) issues in the last year or so.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96732a2f2846
Enable wayland on supported environments by default on Nightly / Early Beta. r=stransky,jrmuizel,aosmond

Comment 16

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/96732a2f2846

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: big deal
[Affects Firefox for Android]: no
[Suggested wording]: Firefox on Wayland support enabled by default (Linux Nightly only)
[Links (documentation, blog post, etc)]:

Comment 18

[Pascal Chevrel:pascalc]

Note added to Nightly release notes.

Comment 19

[mac198442]

Th is need to be backed out causes branding
issues where uses Firefox release branding instead of the intended nightly branding.

Comment 20

[Darkspirit]

(In reply to mac198442 from comment #19)

issues where uses Firefox release branding instead of the intended nightly branding.

Your self-made Nightly.desktop file needs to define the desired icon because Nightly is not packaged: bug 1751153 comment 19 (bug 296568, bug 1530052)