[I support this PR being merged, this is just a comment about whether the related issues should be closed or not.]

IMO this should not close the linked issues, as it is a workaround that removes a desirable (partly/significantly broken) feature. Those issues are not solved, we just avoid running into them by removing the feature that's broken.

We can certainly update and explain to the folks in those threads that they won't be hitting this issue. But, ideally, I hope the "run in the background" feature will be restored to working condition in the long term.

It should close them as it fixes them. You may open other separate issues for other features.

I hope this video clarifies the difference between closing a window and quitting a program on macOS:
https://youtu.be/i6IOhuzl68k?t=24

Once the bugs are really fixed, users should be able to close the last Atom window and still have Atom running in the background. It's very common on macOS. It's how Safari, Firefox and Chrome work, as well as Visual Studio Code. Pretty much any GUI program that can open multiple documents/pages works this way in macOS. Closing and Quitting are often totally separate actions on macOS.

So it's sad to see that feature go away, and those original issues are not "fixed," we just took a feature away. Taking the feature away isn't the same as fixing it. Fixing the bugs and restoring the functionality should be done as soon as possible.

Hey, please solve the issue with Atom not quitting on macOS. Even a work-around would be great.

"Closing and Quitting are often totally separate actions on macOS."

Yes, I know. But Atom can only be closed with force quit. And it can be reproduced everytime.

Hey, please solve the issue with Atom not quitting on macOS. Even a work-around would be great.

"Closing and Quitting are often totally separate actions on macOS."

Yes, I know. But Atom can only be closed with force quit. And it can be reproduced everytime.

Thanks for the comment. I know it is a horrible situation, but this PR fixes it.

You no longer need to force quit Atom just to update a package, Atom will not block your computer from shutting down or logging off, and in the background, it will not eat your memory, CPU resources, and battery, and you can quit Atom whenever you want.

One of the greatest of all mac apps -- namely Calculator -- quits when you close its window. So, Atom will be in good company if it does the same. I've stopped using Atom since I can't quit; it would be great to be able to use it again.

The status quo described in #17672 means that a bug in Atom prevents both logging out the current macOS user and cleanly shutting down a machine. This is far, far worse than the process of launching Atom taking a little more time. I therefore support merging this pull request if it reliably solves the Atom-fails-to-quit bugs. Personally, I consider keeping Atom running in the background after the last window has been closed a mere afterthought, given that users can simpliy minimise Atom.

Thanks to some strong leads/initial investigation by @aminya and @Aerijo, and people's helpful description of the problem in the relevant issues, I think I've found an actual fix for the underlying problem? Pull request: #21847

Feel free to test this and let me know if it works for you. It's working for me locally, anyhow.

Download link: https://dev.azure.com/DeeDeeG/_apis/resources/Containers/11602065/atom-mac.zip?itemPath=atom-mac.zip%2Fatom-mac.zip https://dev.azure.com/DeeDeeG/b/_apis/build/builds/965/artifacts?artifactName=atom-mac.zip&api-version=6.0&%24format=zip

@DeeDeeG I can not download the file. I get a "not authorized" error.

@mtoensing I see. (I can download that link, but only as I am logged in to my own account! In a Private Browsing window, I also see a "login" prompt).

Here is the build from my pull request: https://github.visualstudio.com/9e67709c-1fe5-47f2-8cf6-4902878a11f5/_apis/build/builds/94308/artifacts?artifactName=atom-mac.zip&api-version=6.0&%24format=zip

All artifacts: https://github.visualstudio.com/Atom/_build/results?buildId=94308&view=artifacts

The link in my previous comment is updated and should work now, as well. (These builds are based on the same code. The PR version has an amended commit message, and a different code comment, but otherwise is identical).

Is this superseded by #21847?

@ThatXliner They are each technically viable solutions to the problem. But they are mutually incompatible.

As far as I can tell most macOS users expect Atom to stay open in the background when the last window closes. (Quitting when the last window closes would be a surprise, then.) In which case the other PR #21847 is the desirable solution. If Atom users on macOS offer strong feedback that they'd like Atom to quit when the last window closes, then this current PR is the right solution.

If folks want to take some sort of poll of Atom's macOS users, I suppose we could try to find out what people really prefer.

There has not really been a discussion on that, so I think restoring the current behavior to working order is correct for now. That means going with #21847

P.S. My apologies to @aminya. If looking at this strictly technically, this PR is just as much a correct solution as my PR.

However, like I said, I think not changing the app behavior for the sake of a bug fix PR is the better approach for the existing users.

IMO, #21847 is the way to go. Safari is still open when I close the last window.

But shouldn't it be that when you press "cmd-q" Atom quits cleanly? I have problems when clicking "restart" when updating packages. Or is this already in the current code?

Closing in favour of #21847

@ThatXliner

But shouldn't it be that when you press "cmd-q" Atom quits cleanly?

Yes, and either PR should be adequate to fix that. (Barring another similar issue exists with a different cause).

I have problems when clicking "restart" when updating packages. Or is this already in the current code?

I am looking into that... Hopefully either of these PRs would also fix that. But restarting for updates is its own special process. And startup probably shouldn't be affected by this bug, no-matter what. So it's likely a separate issue.

If anyone has new insights, I'm subscribed to some of the relevant issues, and I'm hopeful someone can track down the problem or at least find a stronger lead on what to look at, or ideal steps to reproduce.

Issues to discuss that in: #21013 or #21751 (fairly active) or #21820 or #17727 (fairly active)