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.
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.
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: