User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36

Steps to reproduce:

My OS is:
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal

Steps:
Run a wayland compositor such as sway
Set the MOZ_ENABLE_WAYLAND=1 environment variable
Install firefox via apt (for me, version with issue is 88.0+build2-0ubuntu0.20.04.1)
Run firefox

Actual results:

Firefox doesn't launch, and console output says: "Error: no DISPLAY environment variable specified"

Expected results:

Firefox should be able to run in a wayland compositor, by setting the MOZ_ENABLE_WAYLAND environment variable. This last worked in version 87.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Is DISPLAY env set? "Error: no DISPLAY environment variable specified" means you're missing X11 display. Wayland still needs it.

This seems strange, I have never needed to set the DISPLAY environment variable before release 88 when running Firefox from within my Wayland Compositor (Sway).

Regardless, I tried it anyway, and I got an error I would have expected:

"Unable to init server: Could not connect: Connection refused"
"Error: cannot open display: :0"

This is the sort of thing I would expect to see when I launch an X11 program in a Wayland context.
Is the XWayland compatibility layer the only option for using Firefox in Wayland as of this release?

I have also verified that Sway is successfully auto-exporting WAYLAND_DISPLAY to the correct value before running.

Can you run Firefox with:

MOZ_LOG="Widget:5, WidgetWayland:5" WAYLAND_DEBUG=1 MOZ_ENABLE_WAYLAND=1

env variables and attach the debug here?

Thanks.

Looks like firefox requires Xwayland to be running, probably could be reproduced on GNOME.
No logs with this envvars, but mozregression says

 2:23.74 INFO: Narrowed integration regression window from [66ff1258, 49a61253] (4 builds) to [d4a0013b, 49a61253] (2 builds) (~1 steps left)
 2:23.74 INFO: No more integration revisions, bisection finished.
 2:23.74 INFO: Last good revision: d4a0013b717fdd3818eb8d3a2783976c56b30a57
 2:23.74 INFO: First bad revision: 49a6125392f5d6ce92443676d6297c46980d4a29
 2:23.74 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d4a0013b717fdd3818eb8d3a2783976c56b30a57&tochange=49a6125392f5d6ce92443676d6297c46980d4a29

#1695453, https://hg.mozilla.org/integration/autoland/rev/49a6125392f5d6ce92443676d6297c46980d4a29

I suppose WAYLAND_DISPLAY is now required? With WAYLAND_DISPLAY=wayland-0 firefox starts just fine.

(In reply to ojab from comment #7)

I suppose WAYLAND_DISPLAY is now required? With WAYLAND_DISPLAY=wayland-0 firefox starts just fine.

Yep, I can confirm, apologies for confusion earlier.
Just a bit alarming, as there was no mention of this new requirement in release-notes/documentation for this scenario.

(In reply to cubed from comment #8)

Yep, I can confirm, apologies for confusion earlier.
Just a bit alarming, as there was no mention of this new requirement in release-notes/documentation for this scenario.

To be fair, WAYLAND_DISPLAY does not need to be set according to spec - I'm just confused to hear that it is not. During my testing it was always set, also in sway. How do you launch it so that it's not set? Just a regular session?

I was mistaken earlier. Sway does indeed set this correctly on launch.
However, I'm also writing my own compositor using wlroots, so it must have been a long day, and I got a bit confused.
Anyway, I don't auto-set this (yet) in our own compositor when starting a new session, that's how I came across this issue.

(In reply to cubed from comment #10)

I was mistaken earlier. Sway does indeed set this correctly on launch.
However, I'm also writing my own compositor using wlroots, so it must have been a long day, and I got a bit confused.
Anyway, I don't auto-set this (yet) in our own compositor when starting a new session, that's how I came across this issue.

Ah ok, that makes sense. In that case I'll keep things as they right now. The current behaviour is arguably not completely correct, but apart from users of unfinished or minimalistic compositors (not suitable for normal Linux distributions) , nobody should be affected.

AFAICS your compositor will need to set WAYLAND_DISPLAY to be fully functional, as e.g. opening a second session would require it to be wayland-1. In theory one can skip it for wayland-0, but I don't see why a production compositor should ever do that.

In my case it was firefox launched via ssh, so something like XDG_RUNTIME_DIR=/… MOZ_ENABLE_WAYLAND=1 firefox.
AFAIK it's not defined what application should do if WAYLAND_DISPLAY is not set, but convention (gtk/qt do that) is to use wayland-0.
So I think this could be closed as WONTFIX (especially since compositors are moving from creating wayland-0 as a default display), but would be better to add explicit error message bla-bla set WAYLAND_DISPLAY if MOZ_ENABLE_WAYLAND=1 because current error is confusing.

…and just tested, with MOZ_ENABLE_WAYLAND=1 DISPLAY=:2 firefox it starts on X11, which is also unexpected.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.