[Bug]: Second launch attempt (while already running) fully boots Chromium/Electron before checking single-instance lock, causing a noticeable delay

[KBeiller]

I have already checked through the existing (both open AND closed) bug reports and found no duplicates

• Yes

App Version

1.13.0-2

Music Server and Version

Navidrome v0.61.2

What local environments are you seeing the problem on?

Desktop Linux

What happened?

Expected Behavior

When Feishin is already running and a new launch is attempted, the new process should detect the existing instance almost instantly and just focus/restore the existing window — similar to how the tray's "Show Window" action is instant.

Current Behavior

Launching Feishin again while an instance is already running takes a noticeable, consistent delay (~0.5s) before the existing window gets focus. This doesn't happen when using "Show Window" from the tray icon, which is instant.

strace -f -tt on the second launch shows a full Electron/Chromium process tree spawning (GPU process, network service, audio service, utility processes) and then exiting, all within about a second:

40870 14:46:14.160838 execve("/usr/bin/feishin", ["feishin"], ...) = 0
...
40905 14:46:15.192085 +++ exited with 0 +++
...
40870 14:46:15.200098 +++ exited with 0 +++

ps -eo pid,ppid,etimes,cmd captured mid-launch shows a brand new top-level Electron process (ppid=1, etimes=0) briefly coexisting with the original instance before disappearing:

39219   1   736   /usr/lib/electron41/electron --enable-gpu-rasterization ... (original instance)
42574   1     0   /usr/lib/electron41/electron --enable-gpu-rasterization ... (new, short-lived instance)

time feishin while an instance is already running (ran twice for consistency):

feishin  0.50s user 0.10s system 114% cpu 0.522 total
feishin  0.50s user 0.10s system 114% cpu 0.524 total

Analysis
This suggests the new process fully initializes Electron/Chromium (GPU, network, audio subsystems) before checking app.requestSingleInstanceLock() and handing off to the existing instance via the second-instance event, rather than checking the lock and quitting first thing in the main process.

AI WAS USED IN THIS ISSUE
I used AI to diagnose and try to get a simple explanation for this issue as I am not yet a linux savy. I reviewed everything and considered this would be helpful. Please provide feedback on the way this issue was opened so I can improve and build better issues for both you and other devs. Thanks.

Steps to reproduce

1. Launch Feishin, let it fully start.
2. Minimize it.
3. Launch Feishin again from a launcher app or through a terminal.
4. Notice the delay before the window comes to focus, compared to using "Show Window" from the tray.

Relevant log output

[KBeiller]

This also happened with Feishin, another electron app. Looks like this is an issue with electron itself, so Claude's analysis is wrong. Here's its analysis:

Follow-up after testing the same scenario on a different Electron app (piec/elecwhat)
I wanted to correct/refine my original analysis. I initially assumed this could be #fixed simply by moving the app.requestSingleInstanceLock() check to the very first line of the main process, before app.whenReady(). After digging further, that's not accurate.
On Linux, Chromium uses a zygote process model: when the Electron "browser" process starts, Chromium's native (C++) bootstrap forks the zygote and several helper processes (GPU, network, audio, sandbox) as part of its own internal initialization — before the app's JS entry point runs at all. This is documented behavior, not app-specific:

Chromium docs: docs/linux/zygote.md
electron/electron#1101 — "Disable zygote on Linux" (open since 2015)
electron/electron#15795 — confirms Chromium's Linux zygote model spawns a sandboxed child process on boot, before mixed-sandbox/app-level control is possible

Since the fork happens natively before any JS runs, moving requestSingleInstanceLock() earlier in the JS entry point won't prevent it — the child processes are already forked by the time that check executes.
I tested the exact same scenario (time, strace -f -tt, ps snapshot mid-launch) against a different, unrelated Electron app (piec/elecwhat) and observed the identical pattern: a full process tree (zygote/GPU/network/audio helpers) spawning and exiting within roughly the same ~0.4-0.5s window, even though that app's single-instance detection logic itself works correctly (it does log already running, raised the main window).
So this looks like it may be inherent to how Chromium bootstraps on Linux, rather than something fixable with a simple reorder of the lock check. A real fix would likely require avoiding re-executing the Electron binary entirely on subsequent launches — e.g. via D-Bus activation (having the .desktop file / launcher talk directly to the already-running instance over D-Bus, the way many native GTK/Qt apps do), rather than spawning a new process that then has to detect the lock and exit.
I'm leaving this open since the underlying UX issue (perceptible delay vs. instant tray focus) is still real and reproducible, but wanted to flag that the fix is likely more involved than initially suggested, and may not be something specific to Feishin's code at all.