After Fedora 40 upgrade: Desktop icon for default (base image) Firefox is missing in dash

[rugk]

STR

I have Firefox from Flathub as a flatpak installed.
Also, obviously, the default base image Firerox is installed.

In Fedora 39 I had and could pin them both to the dash, one was named “Firefox Web Browser” and the other one “Firefox” IIRC.

Now, i updated to Fedora 40.
After the upgrade, only ne entry is there – the one named “Firefox” – and it starts the flatpak version.

I see no easy way – as a user – to (also) get “back” the “old”/“layered” (by default) Firefox.
As it starts different Firefox profiles (obviously), that is immediately visible.

Debugging

Actually, you can start the base Firefox from the command line, so it is not gone or removed in Fedora 40, as I first suspected:

$ firefox               
[Child 39795, MediaDecoderStateMachine #1] WARNING: Decoder=7fc62b20ce00 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<60>::InitDecoder(AVDictionary**): Couldn't open avcodec: file /builddir/build/BUILD/firefox-125.0.2/dom/media/MediaDecoderStateMachineBase.cpp:167

(You may get weird errors, but it works fine).

As always (i.e. it was the same in Fedora 39), both Firefox instances share the same dash/are shown as the same app – although technically they are different ones. AFAIK this is intended, because they share some identifier, but just so you know… also, in the past you could still launch them separately, which is obviously kinda important rather than how exactly they are shown.
(Tip BTW: If you had one open and wanted to open a new instance of the other one, right-click on the other icon in the dash and choose open new window. This opens a new process apparently and thus opens the real Firefox behind the icon instead of switching to the application.)

$ pwd           
/var/lib/flatpak/exports/share/applications
$ ls -la *firefox*                                                   
lrwxrwxrwx. 1 root root 101 30. Apr 00:07 org.mozilla.firefox.desktop -> ../../../app/org.mozilla.firefox/current/active/export/share/applications/org.mozilla.firefox.desktop

So, this is apparently the entry of the flatpak version. The layered version indeed seems to be missing, or do I miss something?

System

Fresh Fedora 40 upgrade

$ rpm-ostree status -b
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
BootedDeployment:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240430.0 (2024-04-30T00:37:35Z)
               BaseCommit: b502c578667ef64976c8ddb376cd3c9514bab149004ffed6336b1db5888bac72
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC

[siosm (Timothée Ravier)]

This is likely due to https://fedoraproject.org/wiki/Changes/RenameFirefoxDesktopFile.

You can likely use commands similar to what’s in Tips and Tricks :: Fedora Docs to copy the desktop entry for the RPM one and rename it to “Firefox (RPM)” for example.

It’s what I do on my system to know which one I’m using.

[rugk]

Yeah, I see. So what happens is the file has been renamed from firefox.desktop to org.mozilla.firefox.desktop. But as Flatpak Firefox already is named org.mozilla.firefox.desktop the flatpak desktop file overwrites the RPM one… uhm… kinda bad, is not it?

But yes, the commands (adapted for my use case), better fix it:

$ sudo mkdir -p /usr/local/share/applications/
$ sudo ln -s /usr/share/applications/org.mozilla.firefox.desktop /usr/local/share/applications/org.mozilla.firefox-rpm.desktop
$ sudo update-desktop-database /usr/local/share/applications/

(I used a symbolic link as I did not need to modify the file actually, and want to get/keep updates in case the rpm updates the .desktop file.)

This shows the Firefox rpm again as “Firefox”:

Note BTW, how the flatpak is still labeled “Firerox Web Browser” while the rpm/layered Firefox is named “Firefox”. Also, BTW created a PR as the original steps also were not up-to-date.

[rugk]

Okay, strange, this somehow broke after some time/updates. I even changed it to be copied instead of a symbolic link, so I can differentiate the name. I even changed the file name, so potential clashes here do not influence it. And it all seems to work:

$ ls -la /usr/local/share/applications
insgesamt 24
drwxr-xr-x. 2 root root 4096 20. Mai 22:15 .
drwxr-xr-x. 3 root root 4096  1. Mai 14:37 ..
-rw-r--r--. 1 root root  371 20. Mai 22:15 mimeinfo.cache
-rw-r--r--. 1 root root 9548 20. Mai 22:15 org.mozilla.firefox-rpm.desktop
$ head org.mozilla.firefox-rpm.desktop 
[Desktop Entry]
Version=1.0
Name=Firefox RPM
GenericName=Web Browser
GenericName[ca]=Navegador web
GenericName[cs]=Webový prohlížeč
GenericName[es]=Navegador web
GenericName[fa]=مرورگر اینترنتی
GenericName[fi]=WWW-selain
GenericName[fr]=Navigateur Web

But “Firefox (RPM)” cannot be opened anymore. It finds both browsers, but when I select “Firefox (RPM)” it does not do anything at all:

Also opening links from any other application does not do anything anymore when “Firefox (RPM)” is selected as the default browser:

That said, starting firefox from the command line seems to work absolutely fine:

$ firefox
libva info: VA-API version 1.21.0
libva info: Trying to open /usr/lib64/dri-nonfree/radeonsi_drv_video.so
libva info: Trying to open /usr/lib64/dri-freeworld/radeonsi_drv_video.so
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_21
libva info: va_openDriver() returns 0

This is strange, because the command it executes is exactly the same:

$ grep "Exec" -C 1 org.mozilla.firefox-rpm.desktop
Comment[sv]=Surfa på webben
Exec=firefox %u
Icon=firefox
--
Name[zh_TW]=開新視窗
Exec=firefox --new-window %u

--
Name[zh_TW]=新增隱私視窗
Exec=firefox --private-window %u

--
Name[fr]=Ouvrir le gestionnaire de profils
Exec=firefox --ProfileManager

System

$ rpm-ostree status -b                 
State: busy
AutomaticUpdates: stage; rpm-ostreed-automatic.service: last run failed
Transaction: refresh-md
  Initiator: client(id:gnome-software dbus:1.392 unit:dbus-:1.2-org.gnome.Software@0.service uid:1000)
BootedDeployment:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240519.0 (2024-05-19T00:40:18Z)
               BaseCommit: 909901aa92e630995305f1abce367fcad700d536de7c170104d4663e050ed19e
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
      RemovedBasePackages: noopenh264 0.1.0~openh264_2.4.0-1.fc40
$ firefox --version     
Mozilla Firefox 126.0
$ rpm -q firefox
firefox-126.0-5.fc40.x86_64

/cc @siosm

[rugk]

Also, if I use the same names for the files, flatpak version again seems to overwrite (i.e. take precedence over) anything (in /local/share/applications):

$ sudo mv org.mozilla.firefox-rpm.desktop org.mozilla.firefox.desktop
$  ls -la                              
insgesamt 24
drwxr-xr-x. 2 root root 4096  9. Jun 14:46 .
drwxr-xr-x. 3 root root 4096  1. Mai 14:37 ..
-rw-r--r--. 1 root root  343  9. Jun 14:46 mimeinfo.cache
-rw-r--r--. 1 root root 9548 20. Mai 22:15 org.mozilla.firefox.desktop
$ sudo update-desktop-database /usr/local/share/applications

Then the dash again only shows one version:

…which starts the flatpak version.

Edit: Also reproducible in Fedora Silverblue v40.20240609.0, so I opened an issue here:

Desktop icon for default (base image) Firefox is missing in dash (after Fedora 40 upgrade)

[chrisawi (Chris Williams)]

If your goal is to be able to run them both at the same time, I think that’s always going to have issues. Both versions now have the same app ID, so they are the same app. If it was working before, I think the culprit is probably recent changes in the firefox RPM package, such as: Commit - rpms/firefox - 4fa72a11636af802f282038efbbd31ba442da4cf - src.fedoraproject.org

You can use --no-remote or --new-instance, but that seems to only work as far as the first window. Once you have an instance of each version running, it’s impossible for each firefox launcher to be able to talk to its respective instance, unless you can convince one of them to use a different D-Bus name.

/usr/bin/firefox hardcodes MOZ_DBUS_APP_NAME=firefox. Copying that script to /usr/local/bin and changing that value to anything else seems to make it independent. Of course, you’d need to keep it in sync going forward.

[rugk]

@chrisawi

You can use --no-remote or --new-instance, but that seems to only work as far as the first window.

Okay, strange, tried adding that in the .desktop file, but does not change a bit. Note that running from the command line always works, only when I start it via GNOME dash, it does not start at all (even if no other Firefox is running).
--new-instance and starting Firefox from dash even once crashed my whole GNOME session (login – Okay I forgot to run update-desktop-database there), though I cannot reproduce this.
Anyway, also with update-desktop-database it does not change things.

Having the first start to be independent would already help me a lot, after all.

@chrisawi

/usr/bin/firefox hardcodes MOZ_DBUS_APP_NAME=firefox. Copying that script to /usr/local/bin and changing that value to anything else seems to make it independent.

Interesting, though this – yet again – is harder on Silverblue to modify as the file system is read-only or obvious reason (It’s how atomic desktops work). So I don’t know how to modify it.

@chrisawi

Copying that script to /usr/local/bin and changing that value to anything else seems to make it independent.

Ah, okay, I see, I tried that, but for me it does not work. I first tried it in an existing console, but for some reason I need to open a new shell… anyway. I changed it like this:

$ diff -u /usr/bin/firefox /var/usrlocal/bin/firefox
--- /usr/bin/firefox	1970-01-01 01:00:00.000000000 +0100
+++ /var/usrlocal/bin/firefox	2024-06-10 15:43:40.345585015 +0200
@@ -279,7 +279,11 @@
 then
   export MOZ_APP_REMOTINGNAME=org.mozilla.firefox
 fi
-export MOZ_DBUS_APP_NAME=firefox
+if [ -z "$MOZ_DBUS_APP_NAME" ]
+then
+  export MOZ_DBUS_APP_NAME=firefox-rpm
+fi
+echo "MOZ_DBUS_APP_NAME=$MOZ_DBUS_APP_NAME"
 
 # Flatpak specific environment variables

Anyway, with the -rpm prefix Firefox just crashes when started from the command line:

$ firefox
MOZ_DBUS_APP_NAME=firefox-rpm
[Parent 106264, Main Thread] WARNING: nsDBusRemoteServer: dbus_validate_path() failed!: 'glib warning', file /builddir/build/BUILD/firefox-126.0/toolkit/xre/nsSigHandlers.cpp:187

** (org.mozilla.firefox:106264): WARNING **: 15:42:58.899: nsDBusRemoteServer: dbus_validate_path() failed!
[Parent 106264, Main Thread] WARNING: g_dbus_connection_register_object: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed: 'glib warning', file /builddir/build/BUILD/firefox-126.0/toolkit/xre/nsSigHandlers.cpp:187

(org.mozilla.firefox:106264): GLib-GIO-CRITICAL **: 15:43:00.112: g_dbus_connection_register_object: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild receives IPC close with reason=AbnormalShutdown (t=3Exiting due to channel error.
.77433) Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild receives IPC close with reason=AbnormalShutdown (t=3.74295) Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild receives IPC close with reason=AbnormalShutdown (t=3.8559) Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild receives IPC close with reason=AbnormalShutdown (t=3.83633) Exiting due to channel error.
Exiting due to channel error.
[1]    106264 segmentation fault (core dumped)  firefox
$ firefox
MOZ_DBUS_APP_NAME=firefox-rpm
[Parent 107275, Main Thread] WARNING: nsDBusRemoteServer: dbus_validate_path() failed!: 'glib warning', file /builddir/build/BUILD/firefox-126.0/toolkit/xre/nsSigHandlers.cpp:187

** (org.mozilla.firefox:107275): WARNING **: 15:43:20.925: nsDBusRemoteServer: dbus_validate_path() failed!
[Parent 107275, Main Thread] WARNING: g_dbus_connection_register_object: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed: 'glib warning', file /builddir/build/BUILD/firefox-126.0/toolkit/xre/nsSigHandlers.cpp:187

(org.mozilla.firefox:107275): GLib-GIO-CRITICAL **: 15:43:22.331: g_dbus_connection_register_object: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild receives IPC close with reason=AbnormalShutdown (t=4.74207) [1]    107275 segmentation fault (core dumped)  firefox

This is reproducible. And yes, even if I have the old Firefox closed.
Also, this does not change the behaviour from GNOME dash, it still does not start there Probably, because it crashes now? I don’t know where I may find it out. I tried journalctl, but it does not seem to list anything useful:

Useless journalctl logs

un 10 15:49:24 **** rpm-ostree[111717]: rpm-md repo 'updates-archive' (cached); generated: 2024-05-22T01:41:39Z solvables: 13161
Jun 10 15:50:23 **** rpm-ostree[111717]: Allowing active client :1.550 (uid 1000)
Jun 10 15:50:23 **** rpm-ostree[111717]: client(id:gnome-software dbus:1.550 unit:app-gnome-org.gnome.Software-73631.scope uid:1000) vanished; remaining=0
Jun 10 15:50:23 **** rpm-ostree[111717]: In idle state; will auto-exit in 60 seconds
Jun 10 15:50:54 **** gnome-shell[73336]: Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Die Methode kann nicht aufgerufen werden; Der Proxy ist fürden allgemein bekannten Namen org.gnome.Terminal ohne Besitzer, und der Proxy wurde mit dem Flag »G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START« erstellt
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.Calculator.SearchProvider@13.service.
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.Contacts.SearchProvider@13.service.
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.Nautilus@13.service.
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.Settings.SearchProvider@10.service.
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.clocks@13.service.
Jun 10 15:50:54 **** nautilus[112304]: Connecting to org.freedesktop.Tracker3.Miner.Files
Jun 10 15:50:54 **** systemd[2531]: Started app-flatpak-org.gnome.Calculator-112302.scope.
Jun 10 15:50:54 **** systemd[2531]: Started app-flatpak-org.gnome.Contactas-112303.scope.
Jun 10 15:50:54 **** systemd[2531]: Started app-flatpak-org.gnome.clocks-112309.scope.
Jun 10 15:50:54 **** gnome-shell[73336]: Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Die Methode kann nicht aufgerufen werden; Der Proxy ist fürden allgemein bekannten Namen org.gnome.Terminal ohne Besitzer, und der Proxy wurde mit dem Flag »G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START« erstellt
Jun 10 15:50:54 **** gnome-calculato[112364]: search-provider.vala:127: Failed to spawn Calculator: Der Kindprozess wurde mit Signal 9 beendet
Jun 10 15:50:54 **** systemd[2531]: Started dbus-:1.2-org.gnome.NautilusPreviewer@13.service.
Jun 10 15:50:54 **** daemon.js[112381]: Warning: Reading certificate from stdin since no -in or -new option is given
Jun 10 15:50:54 **** gnome-shell[73336]: Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Die Methode kann nicht aufgerufen werden; Der Proxy ist fürden allgemein bekannten Namen org.gnome.Terminal ohne Besitzer, und der Proxy wurde mit dem Flag »G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START« erstellt
Jun 10 15:50:54 **** rpm-ostree[111717]: Allowing active client :1.550 (uid 1000)
Jun 10 15:50:54 **** rpm-ostree[111717]: client(id:gnome-software dbus:1.550 unit:app-gnome-org.gnome.Software-73631.scope uid:1000) added; new total=1
Jun 10 15:50:54 **** rpm-ostree[111717]: Handling GetPackages for caller :1.550
Jun 10 15:50:54 **** rpm-ostree[111717]: Enabled rpm-md repositories: fedora rpmfusion-free fedora-cisco-openh264 updates rpmfusion-free-updates updates-archive
Jun 10 15:50:55 **** rpm-ostree[111717]: Importing rpm-md...done
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'fedora' (cached); generated: 2024-04-14T18:51:11Z solvables: 74881
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'rpmfusion-free' (cached); generated: 2024-04-20T12:11:51Z solvables: 422
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2024-03-12T11:45:42Z solvables: 3
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'updates' (cached); generated: 2024-06-10T01:23:37Z solvables: 17164
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2024-06-07T11:49:49Z solvables: 119
Jun 10 15:50:55 **** rpm-ostree[111717]: rpm-md repo 'updates-archive' (cached); generated: 2024-05-22T01:41:39Z solvables: 13161

Whereas the other CLI-started crashes are very much a big red errors: Crash logs in journalctl when firefox is started with MOZ_DBUS_APP_NAME=firefox-rpm in Fedora 40, see · GitHub

What I want

As a general note about the issue, I see the reason for the app(s) to be regarded as “one app” and why it happens, but I think, IMHO, this is unfortunate. I have always used both versions, one flatpak and one non-flatpaked, as e.g. WebExtensions or other features are not yet (fully) supported in flatpak.

Actually, I also do not really need to run them side-by-side, I would be fine if the rpm firefox would open at all… I could close the flatpak version and open the rpm one, that would already be better than before the Fedora 40 change here…

[chrisawi (Chris Williams)]

@rugk

Anyway, with the -rpm prefix Firefox just crashes when started from the command line:

You can’t use hyphens here. It’s used to make a bus name like org.mozilla.firefox-rpm, and that’s invalid.

Edit: Technically it seems the D-Bus spec allows them for bus names, but they’re deprecated and highly discouraged. However, Firefox also uses the string in an object path (/org/mozilla/firefox-rpm/...) and that is truly invalid.

[rugk]

@chrisawi

/usr/bin/firefox hardcodes MOZ_DBUS_APP_NAME=firefox.

BTW, as I find this a bad practice (especially as a better way is shown just one line above with a different variable), I’ve opened a issue at their bug tracker (also about the crashes ):
https://bugzilla.redhat.com/show_bug.cgi?id=2291177

[rugk]

@chrisawi

It’s used to make a bus name like org.mozilla.firefox-rpm, and that’s invalid.

Ah thanks, yeah MOZ_DBUS_APP_NAME=firefoxrpm works. I mean, it does not crash when starting firefox from the terminal.

If I start it from GNOME Shell/Dash, it, however, yet again, does not start at all. This has not changed since the (likely) Firefox patch.

I also tried modifying MOZ_APP_REMOTINGNAME as I think this is what needs to match the .desktop file (it says there) and I tried matching it to a renamed org.mozilla.firefoxrpm.desktop file – aka export MOZ_APP_REMOTINGNAME=org.mozilla.firefoxrpm, but that also does not seem to work/help.

[chrisawi (Chris Williams)]

@rugk

If I start it from GNOME Shell/Dash, it, however, yet again, does not start at all.

Well, it works here. All I did was symlink the .desktop file as org.mozilla.firefoxrpm.desktop and copy and edit MOZ_DBUS_APP_NAME in the firefox script. The only part that doesn’t work is that GNOME Shell matches it to the flatpak .desktop file. Changing MOZ_APP_REMOTINGNAME didn’t help.

---

@rugk

I first tried it in an existing console, but for some reason I need to open a new shell

Bash caches PATH lookup. You can clear that cache with hash -r.

[rugk]

Okay tried again and the symbolic link and it works (for whatever reason). So for all others, the current workaround is like this:

1. Copy and adjust the Firefox rpm wrapper script and adjust MOZ_DBUS_APP_NAME and MOZ_APP_REMOTINGNAME:

   $ cp /usr/bin/firefox /var/usrlocal/bin/firefox
   

   Here is a .patch you can apply manually (or with some patch command):

   --- /usr/bin/firefox	1970-01-01 01:00:00.000000000 +0100
   +++ /var/usrlocal/bin/firefox	2024-06-10 16:28:50.192647634 +0200
   @@ -277,9 +277,13 @@
    # We need to link Firefox with desktop file name
    if [ -z "$MOZ_APP_REMOTINGNAME" ]
    then
   -  export MOZ_APP_REMOTINGNAME=org.mozilla.firefox
   +  export MOZ_APP_REMOTINGNAME=org.mozilla.firefoxrpm
    fi
   -export MOZ_DBUS_APP_NAME=firefox
   +if [ -z "$MOZ_DBUS_APP_NAME" ]
   +then
   +  export MOZ_DBUS_APP_NAME=firefoxrpm
   +fi
   +echo "MOZ_DBUS_APP_NAME=$MOZ_DBUS_APP_NAME"
    
    # Flatpak specific environment variables
    
   

   (Generated with diff -u /usr/bin/firefox /var/usrlocal/bin/firefox.)

   Note: You may need to re-do these steps and keep them in sync, when the rpm Firefox is updated and changes are made to this script.

2. Adjust the .desktop icon to use a different file name, so the rpm Firefox appears even when the Firefox flatpak is installed:

   $ sudo mkdir -p /usr/local/share/applications/
   $ sudo ln -s /usr/share/applications/org.mozilla.firefox.desktop /usr/local/share/applications/org.mozilla.firefoxrpm.desktop
   $ sudo update-desktop-database /usr/local/share/applications/
   

For me, it BTW also works that GNOME differentiates between the two Firefox instances running:

Both have the “white bubble” (dot) indicating some windows are open. So I’ll mark this as the solution for now.

[rugk]

The issue with the variable not being able to be overwritten has been fixed since Firefox 128, so I am updating the instructions:

The current workaround is like this:

1. Adjust the .desktop icon to use a different file name, so the rpm Firefox appears even when the Firefox flatpak is installed:

   $ sudo mkdir -p /usr/local/share/applications/
   $ sudo ln -s /usr/share/applications/org.mozilla.firefox.desktop /usr/local/share/applications/org.mozilla.firefoxrpm.desktop
   $ sudo update-desktop-database /usr/local/share/applications/
   

2. You now just need to overwrite the environmental variables MOZ_DBUS_APP_NAME and MOZ_DBUS_APP_NAME. The best solution I found is using a global overwrite with environment.d (help, see man environment.d):

   $ mkdir -p ~/.config/environment.d 
   $ cd ~/.config/environment.d
   $ nano 01_firefoxrpm.conf
   

   There, just add the environment variables:

   #
   # This file is parsed by pam_env module
   #
   # Syntax: simple "KEY=VAL" pairs on separate lines
   #
   
   # see https://discussion.fedoraproject.org/t/after-fedora-40-upgrade-desktop-icon-for-default-base-image-firefox-is-missing-in-dash/114934/13
   MOZ_DBUS_APP_NAME=firefoxrpm
   MOZ_APP_REMOTINGNAME=org.mozilla.firefoxrpm
   

   When Firefox starts, you can go to about:support and verify/find the environmental variables there.

For me, it BTW also works that GNOME differentiates between the two Firefox instances running:

Both have the “white bubble” (dot) indicating some windows are open. So I’ll mark this as the solution for now.