Mailspring doesn't respect "--background" argument and always opens in foreground. Ubuntu 17.10.
This would be a great starter issue for anyone interested in contributing to Mailspring! We parse the --background option here (https://github.com/Foundry376/Mailspring/blame/master/app/src/browser/application.es6#L84) and then presumably that value is lost or never used at some point.
@goransimic92, it's working for me. Try "mailspring -b" instead
OS: Manjaro 17.0.5
@rustamzh, I have tried both arguments and it's same thing. Both Ubuntu 17.04 and 17.10.
Why not make this an in app option?
I can confirm this issue, in Manjaro 17.0.6 both "-b" and "--background" flags don't work, causing Mailspring to launch in foreground.
Hey folks! Launching at system start is already an option in Preferences > General and starts the app in the background. (Though on Linux it checks for /usr/share/applications/mailspring.desktop - we may need to rework it to support the Snapcraft release, and it may not actually be possible inside of the AppArmor sandbox.)
The current flag is --background. I just checked v1.0.11 and it seems to work fine on macOS. It also works on Ubuntu 16 for me鈥攚hen I type mailspring --background on a command prompt using the latest Snapcraft release, the menu bar item for Mailspring appears in the system tray and the main window does not appear. The app also does not appear in the dock. Clicking System Tray > Open Inbox displays the inbox immediately (just a sanity check that it was running in the background.)
I'm not sure what would cause this to not work. Is it possible that mailspring is actually an alias on your command prompt, and is calling the underlying executable without forwarding it's arguments? Try typing mailspring mailto:[email protected] and check that you see a new composer pre-filled with that address.
Also note that the app will only launch in the background if you've completed the onboarding flow (signed in to your Mailspring ID, linked an account, etc.)
For me it's not an alias, because it directly targets /usr/bin/mailspring with --background argument in autostart file.
But something strange is happening because now sometimes it starts in background and sometimes it doesn't. It looks like sometimes there is something happening in between where it ignores argument and starts in front.
That's strange, deleting mailspring auto-generated entry from startup programs and manually adding /usr/bin/mailspring -b seems to solve the problem. I don't think the issue was caused by an alias though, since mailspring mailto:[email protected] launches a pre-filled composer as expected.
@bengotow If I quit Mailspring while it's opened in front and start again with --background option, it doesn't respect it. But if i quit Mailspring while it's closed to system tray it respects --background option.
I'm having this issue currently with Mailspring version 1.4.2-f587b7b7. As @Void97 suggested, if I run Mailspring from /snap/bin/mailspring -b the background flag works fine. Running just mailspring -b starts the app in the foreground, however. No aliases are set, and the mailto:... option above seems to be behaving as expected. My mailspring command points to /snap/bin/mailspring, for additional clarification.
EDIT: It seems that disabling the "Snap user application autostart helper" (see image) fixes the background flag issue on startup for me.

deleting mailspring auto-generated entry from startup programs and manually adding
/usr/bin/mailspring -bseems to solve the problem.
This fix worked for me on ubuntu mate thank you :-)
_[p.s I'm not using the snap version. ]_
In Ubuntu 18.04.1 LTS, using the snap version with the -b or --background options still launch to the foreground, even when manually running it from "/snap/bin/mailspring -b".
Linux Mint 19 - mailspring --background is working good. One bug is that mailspring hasn't icon in tray.
Manjaro KDE - I had the same problem but I solved it this way: I excluded mailspring from session restore at startup.
On Linux, this is an issue, the background option doesn't work.
The output of mailspring --help told me that the -b, --background option is a boolean, so I start the app with mailspring -b true and now it starts in the background always. This is a bug since boolean should mean that the flag itself would be enough for it to start in the background, but for whatever reason, it needs something else after the flag for it to work.
@bengotow If I quit Mailspring while it's opened in front and start again with
--backgroundoption, it doesn't respect it. But if i quit Mailspring while it's closed to system tray it respects--backgroundoption.
this happens the same to me
On Linux, this is an issue, the background option doesn't work.
The output ofmailspring --helptold me that the-b, --backgroundoption is a boolean, so I start the app withmailspring -b trueand now it starts in the background always. This is a bug sincebooleanshould mean that the flag itself would be enough for it to start in the background, but for whatever reason, it needs something else after the flag for it to work.
i tried but it still doesn't work.
wow! the command -b is actually worked. I just quit mailspring (even in the tray icon) then restart the OS then everything works fine now.
my command is: /usr/bin/mailspring -b %U
This is still an issue as i experienced it after installing from AUR, by modifying the command run by autostart to
mailspring -b %U
Works correctly (does ask for a password though)
Seems to be most likely an issue with the installing scripts
Windows 10 user here. Same issue and nothing works...
@bengotow If I quit Mailspring while it's opened in front and start again with
--backgroundoption, it doesn't respect it. But if i quit Mailspring while it's closed to system tray it respects--backgroundoption.
Same here. Ubuntu 18.04.3 LTS.
Same here Ubuntu 20.04 snap
This is still an issue as i experienced it after installing from AUR, by modifying the command run by autostart to
mailspring -b %UWorks correctly (does ask for a password though)
Seems to be most likely an issue with the installing scripts
this works with the snap on kde manjaro autostart setup as well :+1:
Most helpful comment
This is still an issue as i experienced it after installing from AUR, by modifying the command run by autostart to
Works correctly (does ask for a password though)
Seems to be most likely an issue with the installing scripts