Old Pulsar window gets focused first when launching a new one

[m1ga]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

I use multiple Pulsar windows and everytime I create a new one (e.g. in a different folder) an old Pulsar window will be focused first and then it will start and focus the new window.

Video:

Bildschirmaufnahme_20250214_190012.webm

the first window will cover the terminal when I start the second window.

It would be great to just start the second instance without the focus on the first one.

Tested on Fedora and Ubuntu, Pulsar 1.125.2025021005 and 1.125.0

Pulsar version

1.125.0

Which OS does this happen on?

🐧 Red Hat based (Fedora, Alma, RockyLinux, CentOS Stream, etc.)

OS details

Linux fedora 6.12.11-200.fc41.x86_64

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

• start a pulsar instance
• go into a different folder and put the first pulsar window to the background
• start a second pulsar in a different folder

Additional Information:

No response

[savetheclocktower]

I was about to say “that's just how it works,” but after some thought I realize that was just my macOS bias speaking. I'll look into this.

An Electron app has one main process and one renderer process for each window. When you launch via the terminal and already have at least one Pulsar window open, the second main process doesn't last long; once it sees that one already exists, it says “great, you can do this task instead of me,” hands it a note, and exits. The task that the old main process has been given has nothing to do with the existing window, so I can't see an obvious reason why the existing window would promote itself to the foreground. I certainly can't see where the main process tells it to do so.

I'm much more familiar with macOS’s windowing model in which foregrounding an app implicitly foregrounds each one of its windows. Suppose that one Pulsar window is above a terminal window which is itself above a second Pulsar window; macOS tolerates this, but once you click on the Pulsar icon in the dock, the interleaving is defeated, and all the non-minimized Pulsar windows will lift themselves above all other apps’ windows.

So when I first saw your screencast, I thought, “yeah, of course that's how it works.” But I know that on Windows and various Linux window managers it's possible for different windows to be interleaved, and for a new window to foreground itself without foregrounding all the other windows of the same app.

I can't find evidence of either scenario — not of the old window unilaterally promoting itself (or being told to promote itself), nor of the entire app foregrounding all its windows (for which I don't even think a method exists in Electron — I think it's something Electron itself handles on macOS when it needs to happen). So this is a bit of a puzzle.

Thanks for the report!

[m1ga]

Ah, I wasn't sure if the first window is spawning the second window or if the second window is something new (and shouldn't touch the first one). But it makes sense when you say that there is one Electron instance and it will focus window one and that starts window two.
It's always so annoying if you have one pulsar window in the background of screen one, start a new pulsar window on screen two and the old pulsar window on screen one comes to the foreground 😄

But thank you for the detailed reply! I'll check if I can find something when searching for "Electron and focus"

[savetheclocktower]

But it makes sense when you say that there is one Electron instance and it will focus window one and that starts window two.

To be clear: the main process is told to open a new window, and it does. But I can't find where it's explicitly foregrounding the old window, nor can I find evidence that the old window is explicitly foregrounding itself. As far as I know, there's nothing about the Electron architecture that makes this necessary.

So when I get around to investigating this, the next step will be to sprinkle some logging statements throughout the main process code. I'm not 100% certain I can reproduce the same symptoms on macOS given the platform differences I explained above, but I'd be happy to mentor someone on Linux or Windows if they could reproduce this issue and wanted to help fix it. I've also got a Windows machine, so I could still theoretically diagnose this myself from there — it'd just take me longer to get around to it.

[asiloisad]

A similar behaviour is reported in Windows 10. Similar, but no the same. New window is put in the same state as old one, e.g. old one was in background? new one goes to background too.

explorer_0AZDuwO0Qk.mp4

[savetheclocktower]

A similar behaviour is reported in Windows 10. Similar, but no the same. New window is put in the same state as old one, e.g. old one was in background? new one goes to background too.
explorer_0AZDuwO0Qk.mp4

That's… the opposite behavior :) Instead of both windows coming to the foreground, both stay in the background. I've observed this occasionally on macOS. It's equally wrong but in the opposite direction.

So, to summarize: up is down, cats are dogs, shoes are gloves.