User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Run Firefox in Sway.

Actual results:

Firefox only enables features in whitelisted Wayland compositors.

Expected results:

Firefox should not use an XDG_CURRENT_DESKTOP whitelist to enable features:

Firefox whitelists features for desktop environments that are proven bug free. It does not blacklist broken ones as it causes more trouble for users. WebRender (OpenGL rendering) rollout will happen incrementally by desktop environment.

• Using a XDG_CURRENT_DESKTOP whitelist hardcodes a list of "good compositors" in Firefox. There are many Wayland compositors (e.g. wlroots ones: 1). A whitelist is obnoxious for smaller/newer compositors which will never manage to make it in the whitelist. Moreover, if more clients start doing what Firefox does, the number of whitelists to update will grow and will become unmanageable.

• XDG_CURRENT_DESKTOP is unreliable to start with. Many Sway users don't use a display manager, in which case XDG_CURRENT_DESKTOP won't be set.

This behaviour reminds me a lot of bad websites whitelisting only Chrome or Edge and not working (or working with a degraded user experience) on Firefox.

If you really want to avoid being broken because of broken compositors, you should use a blacklist approach if anything.

Ref https://github.com/swaywm/sway/pull/4876

I left some comments on their bug tracker that point out their problem:
https://github.com/swaywm/sway/pull/4876#issuecomment-632568773

The same Sway bug was reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1787407 (https://bugzilla.gnome.org/show_bug.cgi?id=727546)

Is this an upstream bug or not?

If we want to use the same approach as Firefox: since Firefox doesn't work correctly on Sway, should we blacklist it? Or should we introduce a whitelist of apps correctly working on Sway?

But firefox does work correctly on sway. To be fair, firefox does not auto enable wayland on gnome or KDE so I'm not entirely sure how this is an issue.

Good to have this brought up. This is just what I noticed:

As you can't be detected, your users must manually switch preferences to unbreak the file picker, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1639575#c3

Also, if your users report bugs and upload their about:support page, their desktop environment entry is empty. It's unlikely that every user is manually asked for it, so bugs might get mistriaged and not further debugged. All Sway bugs should ideally end up here: https://bugzilla.mozilla.org/show_bug.cgi?id=wayland-sway

File picker:
bug 1635718 comment 9: "Use xdg-desktop-portal for file dialog picker on Wayland as the native one can't use clipboard."
The problem is that it currently needs to be manually disabled on Sway: bug 1639575 comment 3

WebRender rollout:
Gnome/X11: bug 1614523
Gnome/Wayland: bug 1587060: "KDE/Sway may be added later after some tests."
Maybe WebRender will just be enabled by default for all Wayland compositors - at the end?

Apart from that there is no importance to have XDG_CURRENT_DESKTOP=sway other than having it on about:support which simplifies bug triage.

The whitelist is not forever. We intend to support WebRender everywhere, as our only backend. We similarly filter based on all sorts of criteria on Windows, and not because we don't intend to support those users :).

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #5)

Apart from that there is no importance to have XDG_CURRENT_DESKTOP=sway other than having it on about:support which simplifies bug triage.

Right now if you're using an unknown graphical environment it will show up as "unknown" on about:support even if you have $XDG_CURRENT_DESKTOP correctly set (the person triaging has no idea what environment you're using unless they specifically ask). The diff below "fixes" this for Sway but not really because other unknown environments that the whitelist doesn't know about will still be listed as "unknown". The correct thing would probably be to list the value of $XDG_CURRENT_DESKTOP instead of "unknown" or something like "unknown ($XDG_CURRENT_DESKTOP)".

diff --git a/widget/GfxDriverInfo.cpp b/widget/GfxDriverInfo.cpp
--- a/widget/GfxDriverInfo.cpp
+++ b/widget/GfxDriverInfo.cpp
@@ -737,6 +737,7 @@ const nsAString& GfxDriverInfo::GetDeskt
     DECLARE_DESKTOP_ENVIRONMENT_ID(LXDE, "lxde");
     DECLARE_DESKTOP_ENVIRONMENT_ID(Openbox, "openbox");
     DECLARE_DESKTOP_ENVIRONMENT_ID(i3, "i3");
+    DECLARE_DESKTOP_ENVIRONMENT_ID(Sway, "sway");
     DECLARE_DESKTOP_ENVIRONMENT_ID(Mate, "mate");
     DECLARE_DESKTOP_ENVIRONMENT_ID(Unity, "unity");
     DECLARE_DESKTOP_ENVIRONMENT_ID(Pantheon, "pantheon");
diff --git a/widget/GfxDriverInfo.h b/widget/GfxDriverInfo.h
--- a/widget/GfxDriverInfo.h
+++ b/widget/GfxDriverInfo.h
@@ -246,6 +246,7 @@ enum class DesktopEnvironment : uint8_t 
   LXDE,
   Openbox,
   i3,
+  Sway,
   Mate,
   Unity,
   Pantheon,
diff --git a/widget/GfxInfoX11.cpp b/widget/GfxInfoX11.cpp
--- a/widget/GfxInfoX11.cpp
+++ b/widget/GfxInfoX11.cpp
@@ -409,6 +409,10 @@ void GfxInfo::GetData() {
       CopyUTF16toUTF8(
           GfxDriverInfo::GetDesktopEnvironment(DesktopEnvironment::i3),
           mDesktopEnvironment);
+    } else if (currentDesktop.find("sway") != std::string::npos) {
+      CopyUTF16toUTF8(
+          GfxDriverInfo::GetDesktopEnvironment(DesktopEnvironment::Sway),
+          mDesktopEnvironment);
     } else if (currentDesktop.find("mate") != std::string::npos) {
       CopyUTF16toUTF8(
           GfxDriverInfo::GetDesktopEnvironment(DesktopEnvironment::Mate),

emersion, and everyone reading this and using Sway: the Webrender roleout on X11 will probably take some more time, however I'd be tempted to enable it on all Wayland compositors or at least on non-kwin. Do you know if Wayland+Webrender is generally similar stable as Wayland+basic on Sway?

I have been using FF + WR + Sway for a year and I can say most if not all of the nagging issues have been resolved. Specifically I can't remember the last time I had a wayland issue that was webrender related. Intel HD graphics.

Only issues that remain for me are certain popups do not render (at least not visibly) on displays other than the laptop's built in, but I've just checked and it does not seem to be WR related.

Robert, I haven't seen bug reports specific to WR in the last months. There's still a multi-monitor popup issue that Luis mentioned, but that sounds like a Sway bug and is not specific to WR. I've been personally using WR on AMD and haven't noticed any bug for a while.

So it's a +1 from me.

Regarding the original issue, thanks for clarifying that the XDG_CURRENT_DESKTOP whitelist is just temporary.

Darkspirit, Sway will continue not setting XDG_CURRENT_DESKTOP. I guess we can close this.

@emersion, just had a look at sway and wlroot's issue trackers and haven't found anything about the popup issues in Firefox, should I go ahead and open a report, and if so, which repo would be best? Thanks.

Ah, it seems we just discussed about it on IRC. Opened an issue to track the bug: https://github.com/swaywm/sway/issues/6147

Opened bug 1701977 - marking this as a duplicate, hoping we don't need (more) allow-/blocklisting on Wayland