I maintain TurboVNC, a modern Xvnc implementation derived originally from TightVNC and TigerVNC, and users have reported this problem both with the Firefox snap on Ubuntu 22.04 and with Podman on Fedora.  I wanted to add some clarifying remarks:

- The reason why Linux remote desktop solutions such as TurboVNC call dbus-launch to create a unique session bus instance for each remote desktop session is because, if we don't, we can't have multiple simultaneous remote desktop sessions under the same user account.  Granted that GNOME 3+ doesn't seem to officially support multiple simultaneous sessions, but in practice, it mostly works as long as each session has a unique session bus instance.  MATE and Xfce fully work with multiple simultaneous sessions (except for cgroup issues like this, which aren't related to the window manager.)

- TigerVNC, in v1.11, adopted a completely different approach for launching VNC sessions, using a systemd service that emulates a GDM login.  Thus, it is "fully baked" from systemd's point of view and doesn't experience this issue.  However, the price you pay is that only root can start/stop VNC sessions, and only one session (including VNC and local sessions) can run simultaneously.  Also, this new approach eliminated the ability to use TigerVNC on non-systemd operating systems (FreeBSD) at all.  Referring to the tigervnc-users mailing list, it was a somewhat unpopular move, so we have chosen to stick with the traditional (vncserver) approach in TurboVNC.  However, it would be really nice if we could figure out how to get what we want (multiple simultaneous sessions under the same user account) without having a "half-baked" desktop.

- As near as I can tell, you can get all of the benefits of TigerVNC's approach by simply foregoing the creation of a new session bus instance and using the one that systemd provides, with the caveat that only one session at a time can use the systemd-provided session bus instance.  Someone who understands more about systemd than I do will have to tell me whether this is still half-baked (maybe 3/4-baked) or not, but it does eliminate this specific cgroup issue.  (Those who care to experiment can use the latest pre-release build of TurboVNC, downloadable from https://turbovnc.org/DeveloperInfo/PreReleases, and set TVNC_SHAREDDBUS=1 in the environment to force a new session to use the systemd-provided session bus instance.)

- Setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus before launching Firefox, i.e. telling Firefox to use the systemd-provided session bus instance, is a problematic workaround.  If another session, such as a local session, is using the systemd-provided session bus instance, then this will cause some of the dialogs in Firefox (for instance, the certificate import dialog) to appear in the other session rather than in the remote desktop session.  If there is no session using the systemd-provided session bus instance, then those dialogs will not appear at all.

- Unsetting DBUS_SESSION_BUS_ADDRESS as a workaround avoids the aforementioned dialog issues, but I have seen Firefox complain about this, something to the effect of being unable to save something to the D-Bus session.  I don't remember the exact error message, and I can't currently reproduce it.

tl;dr: It seems like an oversight that systemd won't allow multiple simultaneous remote desktop sessions under the same user account without the sessions being half-baked, and IMHO, this is a competitive disadvantage for Linux vs. Windows (which does support multiple simultaneous remote desktop sessions under the same user account, at least in Windows Server.)  Maybe someone can convince me that I'm a pig-ignorant philistine for believing that Linux should have this capability.  I don't confess to be anything close to a systemd expert.  I just know that our use case used to work perfectly fine, but GNOME 3 started breaking some things with it, and now cgroup v2 is breaking more things with it.  So I would love to know how to support our use case in a manner that is blessed by systemd, if such is even possible.  (It may not be.)