After upgrading to hirsute (which uses wayland in the default desktop session) I noticed a couple issues with the firefox snap. The first one was that the firefox snap would fail to display correctly at all - and it seems this was already discussed in Firefox update 87.0-3 breaks Bookmark Menu and is fixed in firefox 88 which is currently in the beta channel.
The second issue is that when say opening a link in another application (and so then calling out to xdg-open to open that link in the existing firefox instance) - fails to have the link open in the existing firefox instance and instead a dialog pops up after a while saying:
Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.
It seems the firefox snap isn’t correctly enabling the right IPC under wayland so that a second instance can instruct an existing instance to open a link etc. This can be fixed by manually setting the MOZ_DBUS_REMOTE=1 environment variable but I feel that this is likely not the best solution - and so probably the best option is for the firefox snap to do this automatically when it detects it is running under wayland.
@oSoMoN can you advise on the best way to proceed to try and get this fixed now that the firefox snap is published by Mozilla themselves and not Canonical? Thanks!
Seems this was reported upstream by @kenvandine previously https://bugzilla.mozilla.org/show_bug.cgi?id=1441894 but appears to be unresolved still. Given we are 1 week away from hirsute releasing can anyone from the desktop team chime in on how we should perhaps proceed here? To function correctly it would seem we need the snap to be updated for MOZ_DBUS_REMOTE=1 and then to try and have the firefox snap either use a fixed name when doing DBus remote comms and then update the snap.yaml to declare this new slot, OR try and figure out if we would be happy to change the snapd dbus interface from the existing:
# bind to a well-known DBus name: ###DBUS_NAME###
dbus (bind)
bus=###DBUS_BUS###
name=###DBUS_NAME###,
to something like:
# bind to a well-known DBus name: ###DBUS_NAME###
dbus (bind)
bus=###DBUS_BUS###
name="###DBUS_NAME###{,.*}",
(which is similar to the name granted when using mpris by snapd - included below for reference)
Yes there are still some issues since FF 87 snap switched to wayland.
I do use FF 88 snap. The clicks issue is solved, I confirm this.
But it remains the issue you are reporting here. Very annoying! And I cannot access /usr/share with FF wayland, but I can running FF X11.
I believed all these issues were related to the snap confinment, but there are not, as wrote Olivier in my BR:
I looked at upstream bug #1441894, and given how the code is architected, I doubt the proposed solution to use one single well-known bus name (org.mozilla.firefox) and differentiate instances with separate object paths can work: each running instance claims a name on the session bus, hence the need for unique names that contain the base64-encoded profile name.
Your suggestion to change the snapd dbus interface to allow adding a wildcard suffix to the well-known name sounds reasonable to me, and hopefully it is acceptable to the snapd team.
A temporary band-aid would be to have the firefox snap claim the org.mozilla.firefox.ZGVmYXVsdA__ slot, because this corresponds to the profile named “default”. This would at least make the most common use case (one single profile with the default name) work:
$ echo -n default | base64 | tr = _
ZGVmYXVsdA__
Even if we propose that change upstream, the firefox 88.0 release is just around the corner and there’s no guarantee the change would be accepted in the RC at this stage.
I submitted a PR against snapd to allow a wildcard suffix to the ‘well-known’ D-Bus name being claimed. Let’s see if this is acceptable from an interface perspective.
