Linux: Mailspring fails to activate already-running instances

Bug Reports
#1

Description

The Mailspring “single instance” code on Linux is very unreliable. Launching Mailspring will sometimes bring up the existing instance (as intended). Other times, usually after a long wait (it seems), it will instead start a new instance, upon which further calls to the “mailspring” command will bring up that new instance, while the old one also runs in the background simultaneously. After enough time passes, even the new instance will be “forgotten” and the “mailspring” command will spawn yet another instance.

Screenshots

The first instance was the auto-started one at system startup. The second was created when I attempted to launch the Mailspring app.

image
image858×146 56.9 KB

image
image1531×184 17.3 KB

To Reproduce…

Steps to reproduce the behavior:

  1. Install Fedora Workstation 36. You can use a virtual machine, I guess.
  2. Install the AppIndicators GNOME extension, so that you can see Mailspring’s tray icon.
  3. Install Mailspring from the native RPM installer on your website.
  4. Set Mailspring as GNOME’s default mail client.
  5. Bind the GNOME Settings: Keyboard: Launchers: Launch email client to a key, such as Super+E.
  6. Reboot the computer and let Mailspring launch at startup.
  7. Wait and just do other stuff for a few hours (I really don’t know how long it takes). Don’t open mailspring.
  8. When you finally press Super+E to launch your email client, it will open a new instance of Mailspring instead of activating the existing one. Closing the new instance and running the command again will yet again spawn a new instance. Same thing if you manually run “mailspring” command in a terminal.
  9. If you try to run further instances of Mailspring when the NEW one has spawned, that one will continue getting focus as intended, but if you wait long enough, even that one will be “forgotten” and extra/new instances will spawn instead.
  10. This issue never happens when a Mailspring instance is “fresh”. A fresh instance will always activate itself properly. But given some time, every new instance is forgotten in the end, and the duplicate issue appears.

Expected Behavior

More robust handling of multiple instances is needed.

I suspect that you had to do something sneaky since you’ve also got a Snap version (which I am not installing, it doesn’t belong outside Ubuntu and even there it’s an abomination). So you are probably using a method of checking instances which works inside containers such as Snap/Flatpak.

I am not sure, but I THINK the proper way to handle this is to register a dbus singleton instance of Mailspring, and then make the mailspring binary’s startup process attempt to “activate existing instance by sending it a message”, and if THAT fails THEN start a new instance of Mailspring, or QUIT if the existing instance responded.

I even suspect that you may be doing something like that already, but perhaps the dbus registration is being forgotten after a while.

Setup

  • OS and Version: Fedora Workstation 36, fully updated as of this writing
    • Installation Method: .rpm
  • Mailspring Version: 1.10.3-a476c230
#2

I am also curious: Is there risk of database corruption when two instances run simultaneously like this? I get very worried about it.

#3

I would add as well, this is currently breaking protocol handling. With a background instance (as per defaults), the newly launched copy that gets the URL just dies and never passes its URL to the running instance. So, the “activate existing instance” code needs to also pass arguments/URLs to the running instance.

1 Like
#4

I stopped using the “launch email” keyboard shortcut due to this bug. Has anyone noticed if the bug still exists?

#5

:frowning: These forums are dead. GitHub Issues was better.

#6

+1 on this issue. Unlike any other app I have to tippy toe around how I launch this one by only reopening a running instance through the app panel indicator. I can’t even click on a email link to write an email without it opening a new instance.

#7

I still see this issue. I’m using Ubuntu 22.04, which already comes with the AppIndicators extension by default. I installed Mailspring from the official .deb.
This only happens after a good amount of time has passed between opening Mailspring and experiencing this bug.

For me, an easier way to reproduce this issue is just clicking on any mailto link on a website. Mailspring will take a long time to think and eventually open a second instance. Anything that requires your OS to open a mail client, either to send an email or whatever other task, will open a second instance.

It’s going to be almost two years since this was originally reported but we still see this issue.