1752398 - (wayland-stable) [Meta] Ship the Wayland backend to release

Status: RESOLVED FIXED

(Core :: Widget: Gtk, task)

Comment 5

[Emilio Cobos Álvarez [:emilio]]

I really think we should just do this. Realistically there are a bunch of xwayland-only bugs that are not going to get fixed. We've been running it enabled by default on early beta and earlier for more than a year now, and tests are close but not quite there...

Ryan, do you know who would I need to get signoff from product to do this? Or would just gfx/widget reviewers suffice?

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1752398 - Let wayland ride the trains to release. r=stransky!,jrmuizel!

Comment 7

[Darkspirit]

Without showing a notification to suggest users to switch to a package (debian, snap, flatpak), Firefox would lose its desktop icon and all users would need to create a .desktop file manually.
The "default browser" mechanism has not been fixed to create a correct ~/.local/share/applications/MOZ_APP_REMOTINGNAME.desktop file first - in case a system-wide MOZ_APP_REMOTINGNAME.desktop is missing - and then to set MOZ_APP_REMOTINGNAME as default app for https and http. It still creates a useless icon-less ~/.local/share/applications/userapp-Nightly-DGNBC2.desktop file.

Comment 8

[Darkspirit]

bug 1825886 would not be needed if Firefox would have a corrected "default browser" mechanism and would be able to show an alert on Wayland: "Do you want to create a desktop entry and to set it as default app? Otherwise Firefox current desktop entry would start a Firefox without icon."

No such alert would be needed if Firefox could detect an old ~/.local/share/applications/userapp-Nightly-DGNBC2.desktop file,
to rewrite it to a correct MOZ_APP_REMOTINGNAME.desktop (that includes an icon),
and - if userapp-Nightly-DGNBC2 has been the default app for https or http before - to set MOZ_APP_REMOTINGNAME as default app for https and http.

Comment 9

[Darkspirit]

Another fix might be to keep ~/.local/share/applications/userapp-Nightly-DGNBC2.desktop (and such), but to detect it and to add "--name userapp-Nightly-DGNBC2" to "Exec=/path/to/firefox" and to add a "Icon=/path/to/firefox/icon.png" line in case those are missing.
That changes the Wayland app id (dbus app name) of Firefox' windows - default of g_set_prgname is MOZ_APP_REMOTINGNAME - to the desktop file name instead of changing the desktop file name to Firefox' default Wayland app id (MOZ_APP_REMOTINGNAME).

Comment 10

[Martin Stránský [:stransky] (ni? me) (PTO till Feb 21)]

As Fedora ships Wayland by default for 4 years I think it's safe to enable for Release too. Although we're missing testsuite coverage there's good testing coverage on Nighly where Wayland bugs are usually found and fixed.

Comment 11

[Martin Stránský [:stransky] (ni? me) (PTO till Feb 21)]

Darkspirit, I'll look at the points you've made.

Comment 12

[Matthias Urlichs]

Realistically there are a bunch of xwayland-only bugs that are not going to get fixed

Given the number (and severity!) of these bugs, at this point using Wayland directly can't possibly be worse, or riskier, than not to. IMHO.

Comment 13

[bbhtt]

I believe https://bugzilla.mozilla.org/show_bug.cgi?id=1856778 should block this as it somewhat breaks a working experience when switching to wayland on the Flatpak builds.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

I am in favor of doing it. we just need to make sure document this decision properly

Comment 15

[The 8472]

bug 1743144 causes certain wayland crashes to go unreported, so there may be some dark matter.
Has the amount been estimated? Are there unclean process exit metrics or something like that that can be compared for X11 and wayland?

Comment 16

[Emilio Cobos Álvarez [:emilio]]

My understanding is that we should be getting reports for those now: https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/toolkit/xre/nsSigHandlers.cpp#134

But if that's not the case we should investigate why. I'll dig.

Comment 17

[The 8472]

Should this trigger crash reports that show up in about:crashes? I provoked a few crashes under sway that resulted in no such crash reports.

Comment 18

[The 8472]

Regarding bug 1859267, I know why this happens and there already are a bunch of bugs on file regarding that.
What I was asking is - since a) you're planning to roll out wayland on stable b) this isn't covered by crash reports - whether there are other statistics on how often this affects users.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8cb2f63a1e70
Let wayland ride the trains to release. r=stransky,jrmuizel

Comment 20

[Emilio Cobos Álvarez [:emilio]]

(In reply to The 8472 from comment #18)

Regarding bug 1859267, I know why this happens and there already are a bunch of bugs on file regarding that.
What I was asking is - since a) you're planning to roll out wayland on stable b) this isn't covered by crash reports - whether there are other statistics on how often this affects users.

I was working on making those catchable by us, see the patch on that bug. That would give us visibility on those crashes.

Comment 21

[Emilio Cobos Álvarez [:emilio]]

(But they don't seem to happen on KWin / Mutter, so it seems not a huge blocker in practice.)

Comment 22

[Sandor Molnar[:smolnar]]

Backed out changeset 8cb2f63a1e70 because it is waiting for more approval. CLOSED TREE

Backout link: https://hg.mozilla.org/integration/autoland/rev/f0c17e2bcee15e36ab358702e60507ae6af0f9ae

Comment 23

[The 8472]

(In reply to The 8472 from comment #15)

bug 1743144 causes certain wayland crashes to go unreported, so there may be some dark matter.
Has the amount been estimated? Are there unclean process exit metrics or something like that that can be compared for X11 and wayland?

With bug 1859267 solved it turns out that this now observable dark matter has been the dominant mass fraction of the universe top crasher on linux nightlies.
Maybe the rollout to stable should be reconsidered?

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5ea5f3e31d58
Let wayland ride the trains to release. r=stransky,jrmuizel,sylvestre

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Please add a relnote nomination for this when you get a chance.

Comment 26

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5ea5f3e31d58

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: major change in the Linux stack
[Affects Firefox for Android]: no
[Suggested wording]: tbd
[Links (documentation, blog post, etc)]:

Comment 28

[Emilio Cobos Álvarez [:emilio]]

Release Note Request (optional, but appreciated)
[Why is this notable]: The Wayland back-end has been on the works for quite a long time, and provides a set of benefits that users and distros previously had to opt into (performance, security, and new features).
[Affects Firefox for Android]: no
[Suggested wording]:

Firefox will default to Wayland when available, instead of XWayland. This was de-facto already a supported configuration via MOZ_ENABLE_WAYLAND=1, since some distros ship it by default.

This allows things like touchpad / touchscreen gestures, swipe-to-nav, per-monitor DPI, better graphics performance...

Note that due to Wayland protocol limitations, Picture-in-Picture windows need an extra user interaction (generally right-click on the window) or a shell / desktop-environment tweak. See bug 1621261 for related discussion and tracking, this post for a KDE configuration, this extension for GNOME.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx121 relnotes.

Comment 30

[The 8472]

Since it's still causing crashes under some circumstances it'll probably help users if the notes also mentioned how to disable it.