Electron based Snaps like Discord seem to restart after opening from its desktop after a few times, when it's supposed to simply bring up the window from the currently running instance in the background

For those who use Snaps like Discord and Element, and prefer not to call it from its system tray icon, you might notice that after having opened and closed the window of the currently running instance a few times, it will just restart. This is incorrect behavior, as other versions like the .deb it is based on do not behave this way.

To be more specific, let’s say we installed Discord’s .deb package and opened discord from a terminal. Then, we open another terminal and also enter discord, which basically simulates what happens when you click the desktop icon again. It outputs:

Discord 0.0.24
Quitting secondary instance.

And then focuses back on the previously opened window, without opening or doing anything else. This is intended behavior and is what also happens on the Flatpak version of Discord (I can’t comment on other versions). You can repeat the discord command as many times as you would like, and it will always output this.

However, if we were to take the Discord Snap and try the same thing, we would get a similar output at first, albeit with some likely sandbox related errors:

Discord 0.0.24
Quitting secondary instance.
Gtk-Message: 19:52:02.243: Failed to load module "xapp-gtk3-module"

(Discord:118179): Gtk-WARNING **: 19:52:02.278: Theme parsing error: gtk.css:1:21: Failed to import: Error opening file /home/constancies/snap/discord/149/.config/gtk-3.0/colors.css: No such file or directory
Gtk-Message: 19:52:02.307: Failed to load module "colorreload-gtk-module"
Gtk-Message: 19:52:02.307: Failed to load module "window-decorations-gtk-module"

But after the fourth or so time of doing this (though it sometimes varies how many instances it takes to trigger this), the app will open in a new instance, replacing the currently running one, which I imagine would be very annoying for someone in a voice call!

A similar thing occurs with the element-desktop Snap. Initially running element-desktop with an instance already running returns:

/home/constancies/snap/element-desktop/47/.config/Element exists: yes
/home/constancies/snap/element-desktop/47/.config/Riot exists: no
Other instance detected: exiting

But after a couple times of running element-desktop from that separate terminal, the app will restart.

I’ve also tested running the apps via running /snap/bin/[the app], or snap run [the app], and they both have the exact same results.

So, what exactly might be causing this? It’s a pretty inconvenient bug, and I’d quite like to help find a way to address it since the Discord Snap would be virtually perfect in my eyes without it.


I moved the thread to the snapcrafters category, they maintain discord, @kenvandine owns element-desktop…

My assumption here is that somehow the desktop-launch script in the gnome extension could/might have some influence to that behavior…

I should point out that this occurs on both KDE and GNOME, though I haven’t tested other DEs (but it shouldn’t matter because it also occurs when launching the app from the terminal).

well, if you want to debug further i guess taking a look at the desktop-launch script in the gnome extension in use by the respective snaps might give some clues … i.e.:

/snap/<extension name>/current/command-chain/desktop-launch

it does some processing of environment variables before it calls “exec $@” in the end which replaces the calling shell (to keep the PID) with the app …

might be the variable processing causes some kind of race condition against how these apps actually check that there is a running instance or some such …

… but i’m wildly guessing here … :slight_smile: