I have Firefox from the beta channel, and it wouldn’t launch on my KDE Neon 20.04 Unstable Edition running on Wayland session.
When I do it from the terminal, I get this:
No protocol specified
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :1
I have XWayland installed, but is there anything I need to do to make it run?
From my experience running Firefox with Mir Wayland:
MOZ_ENABLE_WAYLAND=1 set in the environment to connect to Wayland.HTH
Additionally to what Alan wrote, this needs to be enabled in the firefox snap itself, which is tracked by upstream bug #1631462.
Damn. Seems like they won’t do it until version 87 (probably).
While having Firefox run as a native Wayland client would likely fix things, I’m curious about why it couldn’t connect to Plasma’s Xwayland. Have you had any success running other X11-only snaps? My suspicion is that this is a problem with the snap being able to read the Xauthority file holding the login token for the X11 server.
Could you try running echo $XAUTHORITY from a terminal on a Plasma Wayland session? The output should be a file name, whose name is not security sensitive.
Looking at the Kwin source code, it looks like it will be generating an Xauthority file named like $XDG_RUNTIME_DIR/xauth_*, which our current AppArmor rules don’t grant read access to:
If that’s the case, then we can probably solve this on the snapd side by allowing read access to this path.
/run/user/1000/xauth_gLnrWy
Thank you. That looks like something we could fix on the snapd side.
If you’d like to help verify, you could try editing the AppArmor profile that snapd generated for Firefox to see if it fixes things. This is a bit fiddly, so I would understand if you’d prefer not to.
These are the steps if you’re game:
/var/lib/snapd/apparmor/profiles/snap.firefox.firefox in a text editor. You’ll have to use sudo, as the file is only writable by root.mutter/Xauthority”owner /run/user/[0-9]*/xauth_* r,
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.firefox.firefox
If everything has worked, you should be able to start Firefox now. Note that this fix is only temporary, and will likely be undone if any of the firefox or snapd snaps get updated. The real fix will be to get snapd to include this new rule in the profiles it generates.
And here’s the snapd pull request that would make this profile change permanent:
It looks like this code for setting up the Xauthority file is only a few weeks old at this point, which is probably why you’re one of the first to trip over it. So hopefully we can get the snapd fix in before it makes it to a stable KDE release.
The change in question has been published to snapd’s edge channel, so you should be able to test it by running:
sudo snap refresh --edge snapd
or if the snapd snap is not already installed:
sudo snap install --edge snapd
That should cause the AppArmor profile to be rebuilt, such that snaps should have access to Plasma’s xauth file automatically. You can switch back to the stable version of snapd with:
sudo snap refresh --stable snapdNow, an empty window shows up, and when I launch from the terminal, here’s what shows up:
$ snap run firefox
[GFX1-]: glxtest: libpci missing
^CExiting due to channel error.
[GFX1-]: Receive IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.
My snapd is version 2.49 from the Snap store.
I’ve seen something similar running Firefox on Mir. It could be that you need to add user_pref("gfx.webrender.all", true); to user.js. The following script handles this for Firefox installed as a .deb. If you’re using Firefox from a snap, you may have to alter it to update a profile under ~/snap/firefox: